GDB support for thread-local storage

Andrew Cagney ac131313@ges.redhat.com
Wed Jun 26 19:31:00 GMT 2002


> Daniel Jacobowitz <drow@mvista.com> writes:
> 
>> On Tue, Jun 25, 2002 at 12:18:34PM -0400, Andrew Cagney wrote:
> 
>> > >Adding a suitable version symbol can only help, it can't break
> 
>> > >>anything. If it's there the debugger can use it. If not you can keep
>> > >>doing what you already do, and it seems you really need it even for
>> > >>the normal native cases.
> 
>> > >
>> > >
>> > >You'll never get them to document interface changes in pthreads'
>> > >internal data structures.  You're welcome to try if you like pain more
>> > >than I do.  The only layer the glibc folks support for accessing this
>> > >data is thread_db.
> 
>> > 
>> > Does the current thread-db code at least sanity check version match 
>> > internally?
> 
>> 
>> I don't believe it has any mechanism for this, no.
> 
> 
> Doesn't libthread_db read `struct _pthread_descr_struct' from the
> linuxthreads library in the inferior, rather than knowing the layout
> itself?  So it's actually the inferior's linuxthreads library that
> describes its own structures' layout.

The structure layout will have been compiled into libthread-db.a.  It 
implicitly knows the layout itself.

> It's got *some* defense against version skew.

To defend against version skew, libthread-db needs to check that its 
internals are consistent with the target.  A simple variable value check 
was mentioned.

Andrew




More information about the Gdb mailing list