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