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