Re: [Crash-utility] [PATCH 2/2] Revert "crash_taget: fetch_registers support"

>>> On 2022/09/27 15:27, Lianbo Jiang wrote: >>>> This reverts commit 2f967fb5ebd737ce5eadba462df35935122e8865. John >>>> Pittman reports that it causes a regression issue on the old Vmware >>>> vmcore as below: >>>> >>>> crash> set scope dm_table_create >>>> set: attempting to find/load "dm_mod" module debuginfo >>>> MODULE NAME BASE SIZE >>> OBJECT FILE >>>> ffffffffa0012dc0 dm_mod ffffffffa0000000 102823 >>> /home/2.6.32-754.35.1.el6.x86_64/kernel/drivers/md/dm-mod.ko.debug >>>> scope: ffffffffa0006cf0 (dm_table_create) >>>> crash> whatis struct dm_table >>>> struct dm_table { >>>> uint64_t features; >>>> struct mapped_device *md; >>>> unsigned int type; >>>> unsigned int depth; >>>> unsigned int counts[16]; >>>> sector_t *index[16]; >>>> unsigned int num_targets; >>>> unsigned int num_allocated; >>>> sector_t *highs; >>>> struct dm_target *targets; >>>> struct target_type *immutable_target_type; >>>> unsigned int integrity_supported : 1; >>>> unsigned int singleton : 1; >>>> fmode_t mode; >>>> struct list_head devices; >>>> void (*event_fn)(void *); >>>> void *event_context; >>>> struct dm_md_mempools *mempools; >>>> struct list_head target_callbacks; >>>> } >>>> SIZE: 312 >>>> crash> whatis _name_buckets --->| After using the whatis >>> _name_buckets command, >>>> struct list_head _name_buckets[64]; | >>>> crash> whatis struct dm_table <---| it won't show the contents >>> of the dm_table struct. >>>> struct dm_table { >>>> int undefined__; >>>> } >>>> SIZE: 312 >>>> crash> >>>> >>>> With the patch, this issue disappeared. >>> At first glance, I did not find any part of the patch that can cause >>> the issue. Do you have any detailed information? >>> >>> >> This issue is observed on an old Vmware vmcore, and looks like a > regression >> issue. > > Is the vmcore a .vmss file? or one captured by kdump? > > It's a .vmss file.

>> I tried to dig into the detail, the raw_supply() operation may affect the >> gdb behavior, it >> will store the register values to a cache in the gdb. >> >> So far I haven't got a good solution, let's see if Alex has a better way > to >> fix it, that would be welcome. Any thoughts? > > I suspected that the issue might depend on the debuginfo, but could not > reproduce it with the same 2.6.32-754.35.1.el6.x86_64 vmlinux. > > but even with reverting the patch, I found that "set scope 0" does not > work well, though not sure whether it's related to the issue. > > There may be a different issue, the 'set scope 0' can work in my case. Can you try the '-r' option to work around your issue?

> so I guess that "set scope" with gdb-10.2 has a problem in the > first place. The second issue above might become a clue. > Lianbo, is it possible to look into the issues more? It might > find a better implementation for "set scope". > > Sure. Will try it. But it might be another issue. In my case, after reverting the commit, it can not be reproduced, otherwise, it is always reproduced.