Re: [RFC] Generic support for qGetTLSAddr packet

[Daniel Jacobowitz <drow@false.org>]

On Tue, Dec 07, 2004 at 05:24:10PM -0700, Kevin Buettner wrote:
> > So, unless I completely misunderstood what you had in mind, I'm not
> > in favor of the to_xfer_partial approach.

I thought about it some more also; I think your analysis was right,
there's not much to gain here.  Except... (see bottom).

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

Another thing I was thinking about was the usefulness of
target-agnostic code for this - I think, very small.  We know what the
get-tls-address operation looks like for GNU/Linux, but not (at least
not I) for any other system.  Presumably there's some way to do this on
Solaris too.

Pending more systems with similar problems, it would be nice if we
could organize all the logic into target-specific code.  Here's where
using target_xfer_partial would be convenient.  I visualize something
like this:

  linux-nat.c provides to_xfer_partial, which can provide X

  linux-tdep.c overrides remote.c's to_xfer_partial (this would
  require a bit of fiddling - I think the best way would be to steer
  clear of target inheritance, and use a gdbarch hook called from
  the remote.c version), with another method for providing X

What the arguments to X should look like, I'm not sure.  It would be
nice to pass the objfile directly, but the to_xfer_partial interface is
not friendly to that; it would be logical to pass the link map address,
but that breaks the abstraction.

Hmm....

-- 
Daniel Jacobowitz