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

On 2022/09/27 17:56, lijiang wrote: > On Tue, Sep 27, 2022 at 4:27 PM HAGIO KAZUHITO(萩尾 一仁) < k-hagio-ab(a)nec.com&gt; > wrote: > >> cc Alexey, reverting this affects VMware folks. >> >> 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?

> 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.

MODULE NAME BASE SIZE OBJECT FILE ffffffffa0012dc0 dm_mod ffffffffa0000000 102823 /home/vmcore/2022-09-28-rhel610-754.35.1.el6/usr/lib/debug/lib/modules/2.6.32-754.35.1.el6.x86_64/kernel/drivers/md/dm-mod.ko.debug crash-dev> struct dm_table struct dm_table { int undefined__; } SIZE: 4 crash-dev> set scope dm_table_create scope: ffffffffa0006cf0 (dm_table_create) crash-dev> 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-dev> set scope 0 <<--- unset the scope scope: 0 (not set) crash-dev> struct dm_table struct dm_table { uint64_t features; <<--- but, same as above 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 It looks like gdb-10.2 has some memory, other than "crash_text_scope" in gdb-10.2/gdb/symtab.c.

On the other hand, with crash-7.3.2 "set scope 0" works as expected. crash-7.3.2> mod -s dm_mod MODULE NAME BASE SIZE OBJECT FILE ffffffffa0012dc0 dm_mod ffffffffa0000000 102823 /home/vmcore/2022-09-28-rhel610-754.35.1.el6/usr/lib/debug/lib/modules/2.6.32-754.35.1.el6.x86_64/kernel/drivers/md/dm-mod.ko.debug crash-7.3.2> struct dm_table struct dm_table { int undefined__; } SIZE: 4 crash-7.3.2> set scope dm_table_create scope: ffffffffa0006cf0 (dm_table_create) crash-7.3.2> 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-7.3.2> set scope 0 scope: 0 (not set) crash-7.3.2> struct dm_table struct dm_table { int undefined__; } SIZE: 4 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.

find a better implementation for "set scope".

Thanks, Kazu