Re: [RFC] Generic support for qGetTLSAddr packet

[Kevin Buettner <kevinb at redhat dot com>]

On Tue, 7 Dec 2004 17:00:50 -0700
Kevin Buettner <kevinb@redhat.com> wrote:

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

It's just occurred to me that the encoding of thread-id and
load-module into annex could also handle any necessary OS/ABI related
translations of the load module.  This means that that we wouldn't
need two separate code paths which both call
svr4_fetch_objfile_link_map().

Of course, the load module translation could also be done (assuming an
interface change) prior to the call to_get_thread_local_address(). 
I think this would address both Mark's and Andrew's comments about
remote.c doing somewhat more than expected.

I'll mull it over some more...

Kevin