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(a)redhat.com>
On Mon, Mar 22, 2021 at 4:31 AM Lianbo Jiang <lijiang(a)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(a)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(a)redhat.com
https://listman.redhat.com/mailman/listinfo/crash-utility