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

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

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
>