[RFC] Generic support for qGetTLSAddr packet
Wed Dec 8 00:38:00 GMT 2004
On Tue, 7 Dec 2004 17:00:50 -0700
Kevin Buettner <firstname.lastname@example.org> wrote:
> On Mon, 6 Dec 2004 18:03:55 -0500
> Daniel Jacobowitz <email@example.com> 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
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...
More information about the Gdb-patches