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

[Daniel Jacobowitz <drow at mvista dot com>]

On Thu, Dec 13, 2001 at 03:37:04PM -0800, Andrew Cagney wrote:
> >On Thu, Dec 13, 2001 at 03:04:07PM -0800, Michael Snyder wrote:
> >
> >>OK.  I'd like to see that patch when it's ready.
> >>Do you use only lwp's, or do you use glibc/libpthread threads?
> >>If you use library threads, are you saving their info in the
> >>core file, or are you only saving the info for the lwp's?
> >
> >
> >It's completely thread-package-agnostic.  I dump all LWPs sharing the
> >same VM, as a fairly reliable marker (I'd use 2.4 threadgroups, but
> >LinuxThreads doesn't use them...)
> 
> 
> Ok.  So you're dumping out the raw data that libthread-db would use to 
> recreate the current thread state from the raw LWP state.
> 
> 
> >So there is enough information there for lin-lwp to parse the threads,
> >if we stubbed out its attempts to write, I expect.  But since the
> >current Linux threads model has one thread per process, I can simply
> >use the corefile.c thread support instead, which I'd rather do.
> 
> 
> Er, careful.  I think lin-lwp should be fixed.  lin-lwp should be 
> interpreting the raw LWP data translating it into user level threads. 
> (Why it writes to the target just sounds like a bug.)

Strongly object.

Why?  Because thread_db is only usable natively!  lin-lwp is not fit
for cross or remote debugging and never can be.  I am testing with MIPS
cores on an x86-linux host.  Right now it "works" because thread-db is
not compiled in; if I had an --enable-targets=i386-linux,mipsel-linux
it would be, though.

If you want to break lin-lwp up into pieces such that one of them can
do this, you might as well abandon using thread_db at all.  The kernel
has enough information to tell you about all the threads; it does so.

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