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

[Michael Snyder <msnyder at cygnus dot com>]

Daniel Jacobowitz wrote:
> 
> On Thu, Dec 13, 2001 at 03:43:15PM -0800, Michael Snyder wrote:
> > Good, dumping only the LWPs is the right thing to do, I think.
> > But if that's what you're doing, then the thread-db module should
> > still be useful to you: I know it is on Solaris, which this one
> > was modelled after.  You'll need it if-and-when the thread-to-lwp
> > mapping ever becomes many-to-one (which may be soon).
> 
> See my comments about cross core debugging in my message to Andrew.

Oh, is that what you were talking about?  Sorry, I must have been
confused.

So -- you are talking about building a single GDB that can debug
  1) native x86 linux, and
  2) MIPS multi-threaded linux corefiles.

Is that right?


> > > 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.
> >
> > You can't rely on that assumption in the future.  We need to make
> > all these packages work together.  It won't be a freebie, it will
> > require some work.  But as I say, it works for Solaris gdb.  We
> > just didn't bother making it work for Linux gdb and corefiles,
> > because up until now there were no threads in corefiles on Linux.
> 
> It will require a large amount of work.  For now, threaded core dumps
> work with cross debuggers (because thread_db and lin-lwp are not
> present at all)

Wait -- slow down.  Andrew and I have never seen a threaded core dump
from linux before today.  It's no wonder a native linux debugger doesn't
work with them -- we've never had a chance to make it work.

> but cause internal errors with native debuggers for the
> reasons I explained.  If there is really such vehement opposition to my
> workaround, I'll maintain it as a local patch instead, and leave anyone
> else wanting to do this out in the cold. 

Instead of that, why don't you start a new thread, something like
"hey, I've got these multi-threaded corefiles that none of you 
have seen before, and I need to discuss how to get GDB to support them".

It might be a good idea if you would provide some examples, 
(better still, access to the kernel patch that results in 
their being generated), and tell us what some of the problems are.
Then we can collectively decide what to do about them.

> Please don't take that as any
> kind of threat; the patch fixes something which is obviously broken,

Quibble -- something that has not been supported 
because up until now there was no need for it.

> and I can not justify the time for the significant infrastructure work
> necessary for any other solution.

It's this decision that we want to be involved in.

> Thread_db, as things stand, does not work on core files. 

Cause it hasn't needed to until now.

> Is preventing
> it from trying, and thus crashing GDB, really such a disruptive
> suggestion?

Not necessarily -- but it's not a decision for one person to make, 
while no one else has access to the problem.  Right now you're
the only one with access to these new multi-threaded corefiles.
Are the rest of us going to be seeing them soon?  We might want
to take part in deciding how best to support them.