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

[Pedro Alves <pedro@codesourcery.com>]

On Friday 21 October 2011 10:42:58, Jan Kratochvil wrote:
> 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?

No, it's not the same.  The <library-list/> support, in either the segment or
section variants is completely self-described.  solib-target.c knows nothing
about the target --- the <library-list/> reported tells GDB which unit of
relocation the target uses, either a section or a segment.  Everything is abstracted,
and gdb is given a simplified view.  Your proposal violates that -- gdb still
knows upfront that the target is svr4-ish, and you still go through
solib-svr4.c.  The assumption that there's only one segment is
really nasty too.

The correct solutions are:

 - Report the library list with <library-list>, _and_ make gdb use solib-target.c.
   What minimal extensions would solib-target.c need so that
   we could make that work, without hardcoding "svr4" semantics?  E.g.,
   <library-list> is defined to _not_ return an element for the main executable.
   Would we need an extension (a new element, say?) for that?  Or is the
   qOffsets mechanism sufficient for relocating the main executable?

 - Still us solib-svr4.c, but then don't abuse <library-list>, but instead
   add a new packet and target object to accelerate getting at the link map.
   TARGET_OBJECT_SVR4_LIBRARIES or TARGET_OBJECT_SVR4_LINKMAP or something along
   those lines.

> > 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.

If you're still using solib-svr4.c for other things than fetching the
link map, then it's not a fully target-side one.  If the implementation
ends up with svr4_so_ops installed in the inferior instead of
solib_target_so_ops, then it's not a fully target-side one.

> 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.  

We already have "qGetTLSAddr", and that's used over
gdbarch_fetch_tls_load_module_address -> svr4_lpXX_fetch_link_map_offsets.
Are you thinking of something else?

> I do not find any of the cases to have advantage, though.

One advantage I was considering would be that making the
target manage (and hide from gdb) the shared library event
breakpoint itself, we'd cut the roundtrips of hitting and
stepping over the breakpoint in half (gdb wouldn't see the
step), and we'd make the target always keep that breakpoint
inserted too, avoiding extra plant/unplant roundtrips for
that breakpoint too.  But since with a fully target-managed
DSO list, we'd end up reporting dso loads/unloads
anyway with TARGET_WAITKIND_LOADED (`T05:...:library' in the RSP),
it may not be much of a gain, and, most importantly, we can get
the same benefits with other generic changes, such as teaching
the server side to step over breakpoints itself, and making gdb
be smart to not remove/insert that breakpoint constantly
(`set breakpoint always-inserted on' by default or maybe just
apply that to some breakpoints).  So the benefits indeed
aren't clear.  But that is not to say we won't find benefits
in the future, and we're free to mess up the design.

And that's why I'm personally okay with still using solib-svr4.c,
_provided_ we come up with a new target object (and packets and dtd)
to fetch the DSO list from the link map efficiently.

> > 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+?

Yes.  We need a new packet for a each new target object:

TARGET_OBJECT_AUXV -> qXfer:read:auxv
TARGET_OBJECT_LIBRARIES -> qXfer:read:libraries
TARGET_OBJECT_SIGNAL_INFO -> qXfer:read:siginfo
TARGET_OBJECT_FDPIC -> qXfer:read:fdpid
TARGET_OBJECT_SVR4_LIBRARIES -> qXfer:read:svr4libraries
TARGET_OBJECT_SVR4_LINKMAP -> qXfer:read:svr4linkmap
....

> 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.

-- 
Pedro Alves