[Crash-utility] [PATCH] GDB: fix the failure of 'set scope' command

[lijiang]

在 2021年03月24日 22:51, John Pittman 写道:
> Applied patch and tested against 2 cores known to show the failure.  Once the
> patch was applied, the issue was resolved.
> 
> Tested-by: John Pittman <jpittman at redhat.com>
> 

Thank you for the test, John Pittman.

> On Mon, Mar 22, 2021 at 4:31 AM Lianbo Jiang <lijiang at redhat.com> wrote:
>>
>> Currently, some command such as 'sys' may cause subsequent 'set scope'
>> commands to fail because it may not find the correct symtab associated
>> with PC and SECTION in the find_pc_sect_symtab(), eventually, this will
>> cause the following failure:
>>
>> crash> mod -S 3.10.0-957.el7.x86_64
>> crash> mod -s dm_service_time
>> crash> set scope st_create
>> set: gdb cannot find text block for address: st_create
>> crash> mod -d dm_service_time
>> crash> mod -sr dm_service_time
>> crash> set scope st_create
>> scope: ffffffffc044d270 (st_create)
>> crash> sys
>>       KERNEL: 3.10.0-957.el7.x86_64/vmlinux
>>     DUMPFILE: crash/vmcore  [PARTIAL DUMP]
>>         CPUS: 48
>>         DATE: Sat Aug  3 11:41:00 EDT 2019
>>       UPTIME: 1 days, 10:28:48
>> LOAD AVERAGE: 2.95, 1.02, 0.40
>>        TASKS: 1060
>>     NODENAME: iop053063.lss.emc.com
>>      RELEASE: 3.10.0-957.el7.x86_64
>>      VERSION: #1 SMP Thu Oct 4 20:48:51 UTC 2018
>>      MACHINE: x86_64  (2999 Mhz)
>>       MEMORY: 127.9 GB
>>        PANIC: "SysRq : Trigger a crash"
>> crash> set scope st_create
>> set: gdb cannot find text block for address: st_create
>>
>> To find the correct symtab, let's check whether there is an address
>> mapping to 'block' in the symtab searching loop and the PC is in the
>> range. If the symtab associated with PC is found, and then use it.
>>
>> Signed-off-by: Lianbo Jiang <lijiang at redhat.com>
>> ---
>>  gdb-7.6.patch | 38 +++++++++++++++++++++++++++++++++++++-
>>  1 file changed, 37 insertions(+), 1 deletion(-)
>>
>> diff --git a/gdb-7.6.patch b/gdb-7.6.patch
>> index f64b55fe547a..90629889f8c4 100644
>> --- a/gdb-7.6.patch
>> +++ b/gdb-7.6.patch
>> @@ -2500,4 +2500,40 @@ diff -up gdb-7.6/opcodes/configure.orig gdb-7.6/opcodes/configure
>>  +struct target_desc *tdesc_aarch64;
>>   #include "features/aarch64.c"
>>   #include "features/aarch64-without-fpu.c"
>> -
>> +
>> +--- gdb-7.6/gdb/symtab.c.orig
>> ++++ gdb-7.6/gdb/symtab.c
>> +@@ -2065,7 +2065,7 @@ find_pc_sect_symtab (CORE_ADDR pc, struct obj_section *section)
>> +   struct symtab *s = NULL;
>> +   struct symtab *best_s = NULL;
>> +   struct objfile *objfile;
>> +-  CORE_ADDR distance = 0;
>> ++  CORE_ADDR distance = 0, start, end;
>> +   struct minimal_symbol *msymbol;
>> +
>> +   /* If we know that this is not a text address, return failure.  This is
>> +@@ -2102,10 +2102,20 @@ find_pc_sect_symtab (CORE_ADDR pc, struct obj_section *section)
>> +     bv = BLOCKVECTOR (s);
>> +     b = BLOCKVECTOR_BLOCK (bv, GLOBAL_BLOCK);
>> +
>> +-    if (BLOCK_START (b) <= pc
>> +-      && BLOCK_END (b) > pc
>> +-      && (distance == 0
>> +-          || BLOCK_END (b) - BLOCK_START (b) < distance))
>> ++    start = BLOCK_START (b);
>> ++    end = BLOCK_END (b);
>> ++
>> ++    /*
>> ++     * If we have an addrmap mapping code addresses to blocks, and pc
>> ++     * is in the range [start, end), let's use it.
>> ++     */
>> ++    if ((pc >= start && pc < end) && BLOCKVECTOR_MAP (bv)) {
>> ++        if (addrmap_find (BLOCKVECTOR_MAP (bv), pc))
>> ++            return s;
>> ++    }
>> ++
>> ++    if ((pc >= start && pc < end) && ((distance == 0)
>> ++                                   || (end - start < distance)))
>> +       {
>> +       /* For an objfile that has its functions reordered,
>> +          find_pc_psymtab will find the proper partial symbol table
>> --
>> 2.17.1
>>
>> --
>> Crash-utility mailing list
>> Crash-utility at redhat.com
>> https://listman.redhat.com/mailman/listinfo/crash-utility
>>
>