Re: [patch] Implement qXfer:libraries for Linux/gdbserver

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Tue, 09 Aug 2011 18:56:15 +0200, Paul Pluzhnikov wrote:
> Side note: SO_NAME_MAX_PATH_SIZE == 512 in solist.h is wrong for Linux;
> I am surprised this hasn't bitten anyone yet. Why doesn't it use PATH_MAX ?

I agree, that static array is not nice anyway.


Regarding design merge of solib-svr4.c XML with solib-target.c XML I have
read the threads:
	[RFC] Add expat to the GDB sources
	http://sourceware.org/ml/gdb-patches/2006-07/msg00231.html
	[RFC, take 2] Optional expat
	http://sourceware.org/ml/gdb-patches/2006-08/msg00048.html

and there is opposition by Mark and Eli (and IIRC only by Mark and Eli)
against any additional pre-requisites for some minimal native GDB build.

I have to agree just because of some minor internal design clean up it may not
make sense to break this pre-requisite rule.

Sidenote: readline needs to continue being bundled as even latest (=bundled)
readline release needs to stay forked at least by:
	[patch 2/3] readline-6.2: Workaround "ask" regression
	http://sourceware.org/ml/gdb-patches/2011-05/msg00005.html
But work is continuing in general to make the possibility of dropping bundled
readline, where it turns from current technical reasons to political reasons.

solib-svr4.c should be split etc. but I find it now outside of the scope of
this patch.


I would therefore find OK to just technically merge the XML parsing in
solib-svr4.c and solib-target.c into some solib.c for example to be called
from both points (if it still makes sense after the changes requested below).

Besides that there are some bugs in the current solib-svr4.c implementation.
If you:
	prelink -R /lib64/libc-2.14.90.so
Then it will:
Sending packet: $qXfer:libraries:read::0,fff#d5...Packet received: l<library-list>\n  <library name="/lib64/libc.so.6"><segment address="0x0"/></library>\n  <library name="/lib64/ld-linux-x86-64.so.2"><segment address="0x0"/></library>\n</library-list>\n
warning: while parsing target library list (at line 2): No segment defined for /lib64/libc.so.6

Which is correct, because `l_addr' being sent as `segment address' is just
in-memory vs. in-file-at-program-start-time displacement, on prelinked system
l_addr is normally always 0.

This also violates the current protocol description:
gdb.texinfo
@node Library List Format
The segment or section bases are start addresses, not relocation offsets; they
do not depend on the library's link-time base addresses.

So either gdbserver needs to find the real base address of the library (which
is IMO possible only by searching /proc/PID/maps for l_ld mapped object and
taking its base address).  Or a different XML attribute needs to be used.

It also needs to pass l_ld address as it is being used by lm_addr_check to
match up the host in-file bfd addresses to the target in-memory addresses
across various prelink situations.  There are 4 different addresses present at
the same time during debugging:
(1) in-memory target base address where library has been loaded
(2) in-file base address the time the library has been loaded,
    which is contained in ELF data structures in the target memory
(3) in-file host base address of library the time debugger has been started
(4) in-file host separate .debug file address (which is always 0)

gdb.base/break-interp.exp should PASS with it, with working <library-list/>,
currently it prints a lot of:
warning: while parsing target library list: no element found

lm_addr_check currently expects it can read so->lm_info->lm being now NULL
with <library-list/>.  But lm_addr_check will start to be needed with
gdb.base/break-interp.exp so one may hit this problem afterwards.

Sorry for the delay, I can return to it in 1-2 weeks (need to push entryval).


Thanks,
Jan