[Crash-utility] Re: [PATCH] Disable DT_DEBUG lookup by GDB inside the vmcore
On Tue, Jul 8, 2025 at 7:48 PM lijiang <lijiang(a)redhat.com> wrote:
Hi, Shivang
Thank you for the fix.
On Mon, Jul 7, 2025 at 7:34 PM Shivang Upadhyay <shivangu(a)linux.ibm.com> wrote:
>
> Crash with GDB 16.2, the following warnings are printed:
>
> crash>
> crash: page excluded: kernel virtual address: c0000000022d6098 type:
"gdb_readmem_callback"
> crash: page excluded: kernel virtual address: c0000000022d6098 type:
"gdb_readmem_callback"
>
> This occurs because the elf_locate_base function in GDB 16.2 attempts
> to read the address of the dynamic linker runtime structure, which is
> present in the .dynamic section of the executable. However, this section
> may be excluded from the dump by makedumpfile.
>
> Commit e906eaca2b1a ("Fix the issue of "page excluded" messages
flooding")
> attempted fix this by suppressing these warnings for regular users, but the
> warnings still appear when crash is started in debug mode.
>
> To fix this, remove the elf_locate_base call in GDB that tries to read the
> .dynamic section, as this information is not useful for debugging kernel
> images in either dump or live kernel scenarios.
>
Good to see it. And we have noticed that some similar debug information also occurs on
x86 64, E.g:
bt: seek error: kernel virtual address: ffffffffffffffc0 type:
"gdb_readmem_callback"
bt: seek error: kernel virtual address: fffffffffffffffb type:
"gdb_readmem_callback"
bt: seek error: kernel virtual address: fffffffffffffffb type:
"gdb_readmem_callback"
This is not always reproduced, but probably the reason should be the same.
In addition, as I mentioned, this issue can not be reproduced on crash 8(gdb-10.2), and I
saw it has the same function call in the elf_locate_base():
Agreed, the same code exists in gdb-10.2 and hasn't reported the
warning message, so the root cause is somewhere else. I'm not
confident that skipping the execution of the code might cause
regressions, because there are kernel modules, which are also elf
files, which might need the inspection of the .dynamic section. At
least I didn't see any evidence from this patch to address it is safe
for the skipping...
Thanks,
Tao Liu
...
/* Find DT_DEBUG. */
if (scan_dyntag (DT_DEBUG, exec_bfd, &dyn_ptr, NULL)
|| scan_dyntag_auxv (DT_DEBUG, &dyn_ptr, NULL))
return dyn_ptr;
/* This may be a static executable. Look for the symbol
conventionally named _r_debug, as a last resort. */
...
This is weird to me. So far I haven't seen a big difference.
Thanks
Lianbo
> Cc: Sourabh Jain <sourabhjain(a)linux.ibm.com>
> Cc: Lianbo Jiang <lijiang(a)redhat.com>
> Signed-off-by: Shivang Upadhyay <shivangu(a)linux.ibm.com>
> ---
> gdb-16.2.patch | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/gdb-16.2.patch b/gdb-16.2.patch
> index 151e4e2..7b79cdf 100644
> --- a/gdb-16.2.patch
> +++ b/gdb-16.2.patch
> @@ -1952,3 +1952,19 @@ exit 0
> }
>
> /* Remember the bfd indexes for the .text, .data, .bss and
> +--- gdb-16.2/gdb/solib-svr4.c.orig
> ++++ gdb-16.2/gdb/solib-svr4.c
> +@@ -742,11 +742,13 @@ elf_locate_base (void)
> + return extract_typed_address (pbuf, ptr_type);
> + }
> +
> ++#ifndef CRASH_MERGE
> + /* Find DT_DEBUG. */
> + if (gdb_bfd_scan_elf_dyntag (DT_DEBUG, current_program_space->exec_bfd (),
> + &dyn_ptr, NULL)
> + || scan_dyntag_auxv (DT_DEBUG, &dyn_ptr, NULL))
> + return dyn_ptr;
> ++#endif
> +
> + /* This may be a static executable. Look for the symbol
> + conventionally named _r_debug, as a last resort. */
> --
> 2.49.0
>
--
Crash-utility mailing list -- devel(a)lists.crash-utility.osci.io
To unsubscribe send an email to devel-leave(a)lists.crash-utility.osci.io
https://${domain_name}/admin/lists/devel.lists.crash-utility.osci.io/
Contribution Guidelines: https://github.com/crash-utility/crash/wiki