This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: question about why gdb needs executable's binary


On Tue, 19 Mar 2019 15:25:15 +0100, Jirka Koutný 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=12249


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]