Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Jim Blandy <jimb@redhat.com>
To: Daniel Berlin <dberlin@dberlin.org>
Cc: gdb@sources.redhat.com
Subject: Re: GDB support for thread-local storage
Date: Wed, 19 Jun 2002 13:40:00 -0000	[thread overview]
Message-ID: <npelf32eah.fsf@zwingli.cygnus.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0206191605590.25507-100000@dberlin.org>


Daniel Berlin <dberlin@dberlin.org> writes:
> > The function one may need to invoke to find thread-local storage,
> > __tls_get_addr, is an actual native code function, in the dynamic
> > linker.  The DW_OP_call_* operations allow a Dwarf expression to call
> > another Dwarf expression like a function.  But you can't use the
> > DW_OP_call_* operations to invoke machine-language functions in the
> > inferior.
> 
> You've assumed you need to.
> If you can transform tls_get_addr into a dwarf expression, there you go.
> You can deref memory, you just can't store into it.
> Since the TLS address is just a location somewhere, computed without 
> modifying anything, one should be able to transform it pretty easily.
> 
> Not that this is the best idea, but it's a possibility.
> :)

We did try to find a way to just express this as a Dwarf expression,
before we resorted to a custom opcode and a libthread_db function.

One objection was that this would embed knowledge about the
implementation of TLS in the executable's debugging info.  The way to
find TLS can change depending on which dynamic linker and thread
library you happen to be (dynamically) linking against.  The process
for finding TLS really should be tightly coupled with the actual
dynamic linker and thread library in use, the way libthread_db is.

One could put the right Dwarf expression in the thread library or
dynamic linker's debugging info, and use DW_OP_call* to invoke it that
way --- that would get the coupling right.  But GDB doesn't apply
dynamic relocs to its debugging info (and it's hard to see exactly how
it could without a lot more help from the dynamic linker --- see Uli's
TLS paper).  This makes it hard to get the right operand for the
DW_OP_call4/8/whathaveyou.

There is also another problem I didn't mention.  You need to know the
module number in order to look up its TLS.  The dynamic linker doesn't
assign the module a number until it's loaded.  But perhaps the Dwarf
expression could actually get that from a GOT entry.


  reply	other threads:[~2002-06-19 20:40 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-19  9:00 Jim Blandy
2002-06-19 10:08 ` Daniel Berlin
2002-06-19 12:20   ` Jim Blandy
2002-06-19 13:12     ` Daniel Berlin
2002-06-19 13:40       ` Jim Blandy [this message]
2002-06-20 18:35 ` Andrew Cagney
2002-06-20 18:48   ` Daniel Jacobowitz
2002-06-21 10:18     ` Andrew Cagney
2002-06-21 10:32       ` Daniel Jacobowitz
2002-06-21 13:08         ` Jim Blandy
2002-06-21 13:18           ` Daniel Jacobowitz
2002-06-21 13:54             ` Jim Blandy
2002-06-21 14:03               ` Daniel Jacobowitz
2002-06-21 14:46                 ` Andrew Cagney
2002-06-21 14:55                   ` Daniel Jacobowitz
2002-06-21 15:31                     ` Andrew Cagney
2002-06-21 22:59                       ` Daniel Jacobowitz
2002-06-22  8:22                         ` Andrew Cagney
2002-06-24  7:53                           ` Daniel Jacobowitz
2002-06-21 16:14                     ` Jim Blandy
2002-06-21 22:57                       ` Daniel Jacobowitz
2002-06-26 12:37                         ` Jim Blandy
2002-06-21 13:20           ` Daniel Jacobowitz
2002-06-21 15:37             ` Jim Blandy
2002-06-21 23:00               ` Daniel Jacobowitz
2002-06-21 12:34   ` Jim Blandy
2002-06-21 12:49   ` Jim Blandy
2002-06-21 18:10     ` Jim Blandy
2002-06-21 20:24       ` Andrew Cagney
2002-06-21 21:09         ` Jim Blandy
2002-06-22  8:31           ` Andrew Cagney
2002-06-21 15:04 ` Andrew Cagney
2002-06-21 15:41   ` Jim Blandy
2002-06-21 15:59     ` Andrew Cagney
2002-06-21 16:08   ` Jim Blandy
2002-06-22  1:04     ` unsuscribe phi
     [not found] <1024952640.13693.ezmlm@sources.redhat.com>
2002-06-25  1:48 ` GDB support for thread-local storage James Cownie
2002-06-25  8:05   ` Daniel Jacobowitz
2002-06-25  8:31     ` James Cownie
2002-06-25  8:42       ` Daniel Jacobowitz
2002-06-25  8:53         ` James Cownie
2002-06-25  8:56           ` Daniel Jacobowitz
2002-06-25  9:11             ` James Cownie
2002-06-25  9:29               ` Daniel Jacobowitz
2002-06-25 10:44             ` Andrew Cagney
2002-06-25 10:02               ` Daniel Jacobowitz
2002-06-26 12:45                 ` Jim Blandy
2002-06-26 19:31                   ` Andrew Cagney
2002-06-26 21:57                     ` Jim Blandy
2002-06-27  8:13                       ` Andrew Cagney
2002-08-19  9:05                       ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=npelf32eah.fsf@zwingli.cygnus.com \
    --to=jimb@redhat.com \
    --cc=dberlin@dberlin.org \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox