This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]