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 <l...@redhat.com> 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 <shiva...@linux.ibm.com>
> 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/aebb370bae3f511df8afb68a01a79c54e2066650
> >
> > > 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.
> >
--
Crash-utility mailing list -- devel@lists.crash-utility.osci.io
To unsubscribe send an email to devel-le...@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
