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.

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