[Crash-utility] Re: [PATCH] Disable DT_DEBUG lookup by GDB inside the vmcore

Hi Shivang, I rechecked the patch you mentioned and made some debug, and my finds are similar to yours: From gdb-10.2 -> gdb-16.2, CORE_ADDR initial = elf_locate_base (); was added into svr4_iterate_over_objfiles_in_search_order(). elf_locate_base() will scan tags as DT_MIPS_RLD_MAP, DT_MIPS_RLD_MAP_REL, DT_DEBUG. The fist 2 will miss for ppc64 vmlinux, however, DT_DEBUG will hit the match, and cause a reading within the .dynamic section. Since .dynamic section is not integrated in vmcore, so reading fails and prompts an error message. gdb-10.2 doesn't have the problem because it won't call elf_locate_base() in svr4_iterate_over_objfiles_in_search_order(). For gdb-16.2, I think skipping DT_DEBUG matching is better, just as your patch does, rather than comment out the CORE_ADDR initial = elf_locate_base () line, since the line deals with namespace staff, not sure any potential side effects. On Fri, Jul 18, 2025 at 9:51 AM Tao Liu <ltao(a)redhat.com&gt; wrote: > > Hi Shivang, > > Sorry for the late reply. The information you provided was very > informative. I'm reviewing and testing against your findings, please > wait a few more while... > > Thanks, > Tao Liu > > On Fri, Jul 11, 2025 at 3:03 AM shivang upadhyay <shivangu(a)linux.ibm.com&gt; wrote: >> >> Hi Tao >> >> Thanks for your feedback. >> >>> Agreed, the same code exists in gdb-10.2 and hasn't reported the >>> warning message, so the root cause is somewhere else. >> >> I believe the change was introduced with this gdb patch [1] >> aebb370 ("gdb, solib-svr4: support namespaces in DSO >> iteration") where the call to elf_locate_base was added >> inside the function `svr4_iterate_over_objfiles_in_search_order`. >> which will be called alot of times during the crash initialization. >> >> [1] >> https://github.com/bminor/binutils-gdb/commit/aebb370bae3f511df8afb68a01a... >> >>> I'm not >>> confident that skipping the execution of the code might cause >>> regressions, because there are kernel modules, >> >> I think `elf_locate_base` part should be only for top level >> target. I have tested the module loading functionality with >> my patch applied, and it still successfully handles the `mod >> -S` command. Please let me know if there’s anything else i >> should try or verify. >> >>> 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... >> >> I wanted to verify whether the kernel ever includes DT_DEBUG >> information. To investigate this, I printed the data being >> read inside the crash::xfer_partial function (which is >> invoked via elf_locate_base to read from the vmcore). >> However, even when running crash with /proc/kcore, all the >> output data was zero. >> >> So, i believe that kernel will never have this `DT_DEBUG` >> information. Could you please redraft your patch log, to include the above info, e.g. related gdb patch hash id, your "mod -S" experiments and results etc, for better future reference? I can ack your patch once the commit message is improved.

Thanks, Tao Liu >> >>> >>> Thanks, >>> Tao Liu >> >> Thanks >> ~Shivang. >>