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

[Pedro Alves <pedro at codesourcery dot com>]

I think this is great,

On Monday 03 October 2011 22:55:30, Jan Kratochvil wrote:
>  should instead include a list of allocated sections.  The segment or
>  section bases are start addresses, not relocation offsets; they do not
> -depend on the library's link-time base addresses.
> +depend on the library's link-time base addresses.  For SVR4 systems
> +are reported parameters @{lm} with address of @code{struct link_map}
> +used for TLS (Thread Local Storage) access, @code{l_addr} specifying
> +bias of the mapped memory address minus the prelinked base address
> +and also @code{l_ld} which is memory address of the @code{PT_DYNAMIC}
> +segment.  SVR4 systems additionally specify @code{struct link_map}
> +address of the main executable in the @code{<library-list>} element.

but this reuse of <library-list> is a mistake.  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, using <library-list> as is
(and having gdb be aware that support is present from
qXfer:read:libraries+ in qSupported).

-- 
Pedro Alves