Re: [RFA] Don't use thread_db on corefiles

[Daniel Jacobowitz <drow@mvista.com>]

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
tonight.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer