Re: GDB support for thread-local storage

[Jim Blandy <jimb@redhat.com>]

Daniel Jacobowitz <drow@mvista.com> writes:
> On Fri, Jun 21, 2002 at 06:14:41PM -0500, Jim Blandy wrote:
> > 
> > One of the reasons I really like having libthread_db handle TLS
> > resolution is that the alternative is to do an inferior function call
> > when you reference a variable.  Check out Uli's document, at the
> > pointer I gave --- even the compiler will sometimes have to generate a
> > call to __tls_get_addr to find a __thread variable's address.
> > 
> > And GDB shouldn't cache this base address while the inferior runs,
> > either --- remember the "GDB must never lie" rule.  Evaluating `x' in
> > GDB had better reference the same storage that it would if the compiler
> > evaluated `x' at the point where the program is stopped.
> > 
> > So if we have trouble keeping the Insight variable window up-to-date
> > now...
> > 
> > Anyway, in that context, having libthread_db handle it all in-process
> > seems really nice.
> 
> Well, libthread_db is still pretty expensive.  It generally does a
> substantial amount of memory access to the inferior.  Cheaper than a
> function call, but not so much.

Well, td_thr_tls_get_addr only makes two calls to ps_pdread.  The
first one is a big one, unfortunately --- it reads a pretty large
structure.

> Part of that is the ridiculous way we use it and abuse the thread_alive
> checks at every opportunity.  If you benchmark some operations on
> libthread_db/native gdb, and gdb/local gdbserver (which uses thread_db,
> but makes some documented assumptions about the threading model, and
> also supports partial stops which I haven't worked out how to do in GDB
> proper) you'll see that the overhead of the remote protocol is
> sometimes less than the overhead of native thread_db.

It seems to me that the right place to handle this is in
proc-service.c, or in the layers below that --- those layers may know
the inferior is stopped, and be able to cache memory contents, etc.