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


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




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