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

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.

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