Re: GDB support for thread-local storage

Daniel Jacobowitz
2002-06-22T05:57:23Z

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.

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.

--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer