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

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

On Thu, 06 Oct 2011 21:09:24 +0200, Pedro Alves wrote:
> but this reuse of <library-list> is a mistake.

<library-list/> already supports the "segment" format and "section" format.
SVR4 attributes are just another format of <library-list/>.
Or do you agree there should rather have been <library-list-segments/> and
<library-list-sections/> and it is kept this way for backward compatibility?


> If we're not going to use
> an solib-target.c at all, and the semantics of what goes over the
> wire is not the same as <library-list>/TARGET_OBJECT_LIBRARIES, then
> let's come up with a completely independent new target object + dtd
> instead.  Let's call it for example TARGET_OBJECT_SVR4_LIBRARIES.


> We should not prevent the possibility of _both_ using solib-svr4.c and
> solib-target.c at the same time, or the possibility of having a completely
> target-side implementation of svr4 libraries in the future,

I find this implementation as the fully target-side one.  SVR4 needs some
information to match symbol files <-> target memory wrt prelinked files and to
aid libthread_db.

Maybe DYNAMIC segment offset could be sent the other way (host->target) to
match the prelink displacement.  And also struct link_map address for
libthread_db may not be transferred and TLS variables could be read by special
packets instead.  I do not find any of the cases to have advantage, though.


> using <library-list> as is (and having gdb be aware that support is present
> from qXfer:read:libraries+ in qSupported).

That is you suggest to have also new qXfer:read:svr4libraries+?


I do not follow how differently / more target-side could be the libraries
implemented on SVR4 systems, I already tried to implement it that way.


Thanks,
Jan