This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: GDB support for thread-local storage
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Jim Blandy <jimb at redhat dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Wed, 19 Jun 2002 16:12:13 -0400 (EDT)
- Subject: Re: GDB support for thread-local storage
On 19 Jun 2002, Jim Blandy wrote:
>
> Daniel Berlin <dberlin@dberlin.org> writes:
> > > Unfortunately, Dwarf 2 location expressions cannot perform function
> > > calls in the inferior.
> >
> > Errr, buzz.
> >
> > See DW_OP_call_* in dwarf3
>
> (As I wrote that sentence, I was wondering whether I should clarify
> this point.)
>
> 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.
:)
>
> > It's not just turing complete anymore, one could probably write useful
> > application extensions in dwarf3.
> > Scary.
>
> I thought so too, but then I noticed that there are no memory store
> operations. You can do stuff on the stack, but you can't modify
> memory, or do any I/O. Grave omissions, which should be rectified
> immediately.
I'm on it.
It also needs a DW_OP_fix_bug
>