在 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@xxxxxxxxxx>
>
Thank you for the test, John Pittman.
> On Mon, Mar 22, 2021 at 4:31 AM Lianbo Jiang <lijiang@xxxxxxxxxx> 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@xxxxxxxxxx>
>> ---
>> 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@xxxxxxxxxx
>> https://listman.redhat.com/mailman/listinfo/crash-utility
>>
>
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/crash-utility
