Re: question about why gdb needs executable's binary

I see, just to make sure - DT_DEBUG gets dumped into the corefile, is that
correct?

Den tir. 19. mar. 2019 kl. 14:35 skrev Jan Kratochvil <
[email protected]>:

> On Tue, 19 Mar 2019 15:25:15 +0100, Jirka Koutn=C3=BD wrote:
> > PT_NOTE can't be read by gdb,
>
> Various PT_NOTESs are read by GDB but not PT_NOTE of type NT_FILE.
>
>
> > That being said, how about dlopen()?
>
> That does not matter, both initially-loaded libraries and dlopen()ed
> libraries
> are present in DT_DEBUG/_r_debug/r_debug the same way.
>
> "initially-loaded library" (which is linked automatically, during
> compilation
> specified by -lNAME) are present in DT_NEEDED but that is for ld.so
> (/lib64/ld-linux-x86-64.so.2) and GDB does not care about those.
> It would be nice if GDB did but that is an unrelated RFE:
>         RFE: preload DT_NEEDED library list
>         https://sourceware.org/bugzilla/show_bug.cgi?id=3D12249
>
>
> > For what I found out about DT_DEBUG this section gets initialized by ld
> as
>
> by ld.so (/lib64/ld-linux-x86-64.so.2), not /usr/bin/ld.
>
>
> > you said. Do I understand you correctly, this is an alternative to the
> > first option, that in fact doesn't require the executable?
>
> yes, sort of alternative.  But NT_FILE is generated by kernel so there can
> appear even shared libraries mmap()ed as data files while in
> DT_DEBUG/_r_debug/r_debug can be found only libraries really opened by
> DT_NEEDED or dlopen()ed.  So there is a subtle difference what those two
> sources of information mean.
>
> Also NT_FILE is generated only by Linux kernel (or GDB) while
> DT_DEBUG/_r_debug/r_debug are present even on non-Linux UNIXes
> (if one thinks there still exist some).
>
>
> Jan
>