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