Re: [RFC] Generic support for qGetTLSAddr packet

[Kevin Buettner <kevinb at redhat dot com>]

On Mon, 6 Dec 2004 18:03:55 -0500
Daniel Jacobowitz <drow@false.org> wrote:

> On Mon, Dec 06, 2004 at 11:37:18PM +0100, Mark Kettenis wrote:
> > That said, I don't understand why there's any need for the remote code
> > to get so deep into the core GDB code.  I don't see the big picture
> > yet, but my initial reaction is that this must be wrong.  Why does the
> > remote protocol need to know more than a native GDB?
> 
> Because shared libraries are handled by GDB, and not by gdbserver. 
> Take a look at thread_db_get_thread_local_address; there's a call
> to svr4_fetch_objfile_link_map in it, which gdbserver can't do
> (unless we were to add ELF header support to it... yuck).

Yes, this is exactly right.

> That said, I wonder if this query should be handled uniquely by
> remote.c, or by GNU/Linux specific code using an xfer-partial
> mechanism.  I haven't thought about the details yet.

I've given this some thought since yesterday.

This approach would define a new enum target_object (maybe
TARGET_OBJECT_TLS_ADDR) and use to_xfer_partial() to handle the
lookup of thread local addresses.  The target method
to_get_thread_local_address() would be eliminated entirely.

As I indicated in my reply to Mark yesterday, we need three
things to fetch a thread-local address.  We need a thread id,
an offset (which is supplied by the debug information), and
some representation of the load module.

The interface for to_xfer_partial is as follows:

    LONGEST (*to_xfer_partial) (struct target_ops *ops,
				enum target_object object, const char *annex,
				void *readbuf, const void *writebuf,
				ULONGEST offset, LONGEST len);

This interface does not make it easy to pass the three TLS related
parameters noted above.  One of them (probably the TLS offset) could
be passed as to_xfer_partial's ``offset'' parameter.  The other two
would have to be encoded in some way and passed as ``annex''.  Each
implementation of to_xfer_partial() would have to implement some
decoding logic in order make use of the two encoded parameters.

Using to_xfer_partial() doesn't really solve the remote protocol
problem either.  remote.c would still need to detect
TARGET_OBJECT_TLS_ADDR and construct a suitable qPart packet.

The problem of the stub not having the load module representation
in an easy to use form would still exist too.

The only advantage that I can think of with this approach is that it
reduces the number of target_ops methods.  (And I don't find this to
be all that compelling.)  The disadvantage is that it complicates the
encoding and decoding of the parameters necessary for fetching a TLS
address.  As noted above, it doesn't help one way or another with
encoding a suitable packet for the remote protocol.  In order to avoid
putting an undue burden on the stub, we'd still need much of the
machinery from my current patch proposal.

So, unless I completely misunderstood what you had in mind, I'm not
in favor of the to_xfer_partial approach.

Kevin