This is the mail archive of the
mailing list for the GDB project.
Re: [RFA] Don't use thread_db on corefiles
On Sun, Dec 16, 2001 at 04:29:34PM -0500, Andrew Cagney wrote:
> >Are we really comfortable with that? This'll probably cause GDB to
> >misbehave in arbitrarily unpredictable ways in that circumstance. And
> >we've no way to detect it that I can see.
> By misbehave I guess you mean exibit non-deterministic behavour. Using
> the current source base, either the GDB build is native and thread-db is
> included (and full thread support in core files is available) XOR GDB is
> a cross, thread-db is not included, and full thread support of core
> files is not available. I think this is pretty deterministic.
What do we really lose when you say "full thread support" is not
available? For a thread == LWP model, everything except possibly
internal LWP numbering is there, as far as I can tell. But that's
beside the point.
> As far as I know, these limitations are exactly the same as for GDB and
> shared libraries. It just so happens that, for shared libraries, things
> are a little (lot) further down the road of getting the technical
> problems fixed.
Not really the same. Debugging shared libraries you need:
- to describe the link map. This is a fixed, generally unchanging,
and simple structure.
- to provide the target libraries.
Debugging threads, you need a libthread_db which can run on the host
and describe the target. The way linuxthreads_db is built it'll never
do that. What worries me is that we have no way to find whether
/lib/libthread_db.so.1 is compatible with the threads in a core dump.
In any case, I'll try to bring it up for a normal native case later
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer