[patch 3/3] Implement qXfer:libraries for Linux/gdbserver #2
Pedro Alves
pedro@codesourcery.com
Thu Oct 6 19:09:00 GMT 2011
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
More information about the Gdb-patches
mailing list