[RFA] Don't use thread_db on corefiles

[RFA] Don't use thread_db on corefiles

[Daniel Jacobowitz]

This patch fixes a really frustrating internal error when you open the
coredump of a multithreaded application.  Depending on your kernel, either
the core has threads (corefile.c supports this just fine) or it doesn't. 
Neither way will opening libthread_db work right.

This patch isn't quite complete, because strange things happen when you
connect to a remote target too.  But fixing that requires a little more
fiddling.

Is this OK?

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

2001-12-13  Daniel Jacobowitz  <drow@mvista.com>

	* thread-db.c (thread_db_new_objfile): Don't use thread_db on
	corefiles.

Index: thread-db.c
===================================================================
RCS file: /cvs/src/src/gdb/thread-db.c,v
retrieving revision 1.18
diff -u -r1.18 thread-db.c
--- thread-db.c	2001/10/13 15:04:02	1.18
+++ thread-db.c	2001/12/13 16:43:08
@@ -482,7 +482,9 @@
 {
   td_err_e err;
 
-  if (objfile == NULL)
+  /* Don't attempt to use thread_db on targets which can not run
+     (core files).  */
+  if (objfile == NULL || !target_has_execution)
     {
       /* All symbols have been discarded.  If the thread_db target is
          active, deactivate it now.  */

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

[Andrew Cagney]

> This patch fixes a really frustrating internal error when you open the
> coredump of a multithreaded application.  Depending on your kernel, either
> the core has threads (corefile.c supports this just fine) or it doesn't. 
> Neither way will opening libthread_db work right.


Daniel, can you explain the problem?  Thread-db should work on core 
files (or realize it is silly and not open its self).


> This patch isn't quite complete, because strange things happen when you
> connect to a remote target too.  But fixing that requires a little more
> fiddling.


Andrew

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

[Daniel Jacobowitz]

On Thu, Dec 13, 2001 at 10:57:27AM -0800, Andrew Cagney wrote:
> >This patch fixes a really frustrating internal error when you open the
> >coredump of a multithreaded application.  Depending on your kernel, either
> >the core has threads (corefile.c supports this just fine) or it doesn't. 
> >Neither way will opening libthread_db work right.
> 
> 
> Daniel, can you explain the problem?  Thread-db should work on core 
> files (or realize it is silly and not open its self).

I suppose it might, theoretically, work on core files - but why bother? 
All we need is the list of threads and their registers, and corefile.c
provides that and adds the threads appropriately.

What the patch does is make thread-db realize it is silly and not open
itself.  It has no code to do that; basically, it will always try to
dlopen(), even if debugging core files or remote code; and if the
dlopen succeeds it will try to use thread-db.

The first thing to go wrong is that we try to enable event reporting. 
That calls ps_pdwrite, which of course doesn't work.  We get a
warning().

Then, every time we attach to a thread we try to enable event reporting
there too, and that's an error().

If we connect to a remote target, as I said, the same thing will
happen; and in that case we'll have host libthread_db and target
libpthread.  That's bad, but I'll not touch it until someone makes
progress on remote thread debugging.

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

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

[Michael Snyder]

Daniel Jacobowitz wrote:
> 
> This patch fixes a really frustrating internal error when you open the
> coredump of a multithreaded application.  Depending on your kernel, either
> the core has threads (corefile.c supports this just fine) or it doesn't.
> Neither way will opening libthread_db work right.

Daniel, what exactly is the problem that you are solving?
What do you mean by "work right"?

> This patch isn't quite complete, because strange things happen when you
> connect to a remote target too.  But fixing that requires a little more
> fiddling.

I don't think that "target_has_execution" is the right thing
to be testing here, if what you're really looking for is
"is this a corefile?"

> 
> Is this OK?
> 
> --
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer
> 
> 2001-12-13  Daniel Jacobowitz  <drow@mvista.com>
> 
>         * thread-db.c (thread_db_new_objfile): Don't use thread_db on
>         corefiles.
> 
> Index: thread-db.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/thread-db.c,v
> retrieving revision 1.18
> diff -u -r1.18 thread-db.c
> --- thread-db.c 2001/10/13 15:04:02     1.18
> +++ thread-db.c 2001/12/13 16:43:08
> @@ -482,7 +482,9 @@
>  {
>    td_err_e err;
> 
> -  if (objfile == NULL)
> +  /* Don't attempt to use thread_db on targets which can not run
> +     (core files).  */
> +  if (objfile == NULL || !target_has_execution)
>      {
>        /* All symbols have been discarded.  If the thread_db target is
>           active, deactivate it now.  */

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

[Daniel Jacobowitz]

On Thu, Dec 13, 2001 at 12:21:48PM -0800, Michael Snyder wrote:
> Daniel Jacobowitz wrote:
> > 
> > This patch fixes a really frustrating internal error when you open the
> > coredump of a multithreaded application.  Depending on your kernel, either
> > the core has threads (corefile.c supports this just fine) or it doesn't.
> > Neither way will opening libthread_db work right.
> 
> Daniel, what exactly is the problem that you are solving?
> What do you mean by "work right"?

Work at all.  Witness:


drow@nevyn:~/crash% gdb ./lotsa_um core
GNU gdb 5.1
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-linux"...
Core was generated by `./lotsa_um'.
Reading symbols from /lib/libpthread.so.0...done.

warning: Unable to set global thread event mask: generic error
[New Thread 1024 (LWP 153)]
Error while reading shared library symbols:
Cannot enable thread event reporting for Thread 1024 (LWP 153): generic error
Reading symbols from /lib/librt.so.1...done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0  main (argc=1, argv=0xbffffec4) at lotsa_crash.c:35
35              *(int *) 0 = 0;
(gdb) info threads
../../gdb/lin-lwp.c:1292: gdb-internal-error: lin_lwp_thread_alive: Assertion `is_lwp (ptid)' failed.
An internal GDB error was detected.  This may make further
debugging unreliable.  Continue this debugging session? (y or n) 

> > This patch isn't quite complete, because strange things happen when you
> > connect to a remote target too.  But fixing that requires a little more
> > fiddling.
> 
> I don't think that "target_has_execution" is the right thing
> to be testing here, if what you're really looking for is
> "is this a corefile?"

Well, the errors are on trying to write to inferior memory mostly.  Tieing that to
target_has_execution made sense to me.

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

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

[Michael Snyder]

Daniel Jacobowitz wrote:
> 
> On Thu, Dec 13, 2001 at 12:21:48PM -0800, Michael Snyder wrote:
> > Daniel Jacobowitz wrote:
> > >
> > > This patch fixes a really frustrating internal error when you open the
> > > coredump of a multithreaded application.  Depending on your kernel, either
> > > the core has threads (corefile.c supports this just fine) or it doesn't.
> > > Neither way will opening libthread_db work right.
> >
> > Daniel, what exactly is the problem that you are solving?
> > What do you mean by "work right"?
> 
> Work at all.  Witness:

What the heck kind of core file is this?  I've never seen
the behavior you're getting.  GDB certainly works for standard
corefiles on Linux (which BTW don't have any thread info in them).

> 
> drow@nevyn:~/crash% gdb ./lotsa_um core
> GNU gdb 5.1
> Copyright 2001 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i386-linux"...
> Core was generated by `./lotsa_um'.
> Reading symbols from /lib/libpthread.so.0...done.
> 
> warning: Unable to set global thread event mask: generic error
> [New Thread 1024 (LWP 153)]
> Error while reading shared library symbols:
> Cannot enable thread event reporting for Thread 1024 (LWP 153): generic error
> Reading symbols from /lib/librt.so.1...done.
> Loaded symbols for /lib/librt.so.1
> Reading symbols from /lib/libm.so.6...done.
> Loaded symbols for /lib/libm.so.6
> Reading symbols from /lib/libc.so.6...done.
> Loaded symbols for /lib/libc.so.6
> Reading symbols from /lib/ld-linux.so.2...done.
> Loaded symbols for /lib/ld-linux.so.2
> #0  main (argc=1, argv=0xbffffec4) at lotsa_crash.c:35
> 35              *(int *) 0 = 0;
> (gdb) info threads
> ../../gdb/lin-lwp.c:1292: gdb-internal-error: lin_lwp_thread_alive: Assertion `is_lwp (ptid)' failed.
> An internal GDB error was detected.  This may make further
> debugging unreliable.  Continue this debugging session? (y or n)
> 
> > > This patch isn't quite complete, because strange things happen when you
> > > connect to a remote target too.  But fixing that requires a little more
> > > fiddling.
> >
> > I don't think that "target_has_execution" is the right thing
> > to be testing here, if what you're really looking for is
> > "is this a corefile?"
> 
> Well, the errors are on trying to write to inferior memory mostly.  Tieing that to
> target_has_execution made sense to me.
> 
> --
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer

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

[Daniel Jacobowitz]

On Thu, Dec 13, 2001 at 02:55:31PM -0800, Michael Snyder wrote:
> Daniel Jacobowitz wrote:
> > 
> > On Thu, Dec 13, 2001 at 12:21:48PM -0800, Michael Snyder wrote:
> > > Daniel Jacobowitz wrote:
> > > >
> > > > This patch fixes a really frustrating internal error when you open the
> > > > coredump of a multithreaded application.  Depending on your kernel, either
> > > > the core has threads (corefile.c supports this just fine) or it doesn't.
> > > > Neither way will opening libthread_db work right.
> > >
> > > Daniel, what exactly is the problem that you are solving?
> > > What do you mean by "work right"?
> > 
> > Work at all.  Witness:
> 
> What the heck kind of core file is this?  I've never seen
> the behavior you're getting.  GDB certainly works for standard
> corefiles on Linux (which BTW don't have any thread info in them).

This is a multithreaded core file :)

It follows the basic ELF standard for multiple threads in one core
file; multiple PRSTATUS notes, the first of which is the thread that
crashed.

I'm still putting some touches on the kernel patch itself.  Stopping
multiple threads so you can dump them is a royal pain.

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

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

[Michael Snyder]

Daniel Jacobowitz wrote:
> 
> On Thu, Dec 13, 2001 at 02:55:31PM -0800, Michael Snyder wrote:
> > Daniel Jacobowitz wrote:
> > >
> > > On Thu, Dec 13, 2001 at 12:21:48PM -0800, Michael Snyder wrote:
> > > > Daniel Jacobowitz wrote:
> > > > >
> > > > > This patch fixes a really frustrating internal error when you open the
> > > > > coredump of a multithreaded application.  Depending on your kernel, either
> > > > > the core has threads (corefile.c supports this just fine) or it doesn't.
> > > > > Neither way will opening libthread_db work right.
> > > >
> > > > Daniel, what exactly is the problem that you are solving?
> > > > What do you mean by "work right"?
> > >
> > > Work at all.  Witness:
> >
> > What the heck kind of core file is this?  I've never seen
> > the behavior you're getting.  GDB certainly works for standard
> > corefiles on Linux (which BTW don't have any thread info in them).
> 
> This is a multithreaded core file :)
> 
> It follows the basic ELF standard for multiple threads in one core
> file; multiple PRSTATUS notes, the first of which is the thread that
> crashed.
> 
> I'm still putting some touches on the kernel patch itself.  Stopping
> multiple threads so you can dump them is a royal pain.

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?

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

[Daniel Jacobowitz]

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

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.

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

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

[Andrew Cagney]

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

Have a look at the discussioin started by Michael on a gcore command.

Andrew

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

[Daniel Jacobowitz]

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

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

[Michael Snyder]

Daniel Jacobowitz 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...)

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


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

Michael

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

[Daniel Jacobowitz]

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.

> > 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) 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.  Please don't take that as any
kind of threat; the patch fixes something which is obviously broken,
and I can not justify the time for the significant infrastructure work
necessary for any other solution.

Thread_db, as things stand, does not work on core files.  Is preventing
it from trying, and thus crashing GDB, really such a disruptive
suggestion?

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

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

[Daniel Jacobowitz]

On Thu, Dec 13, 2001 at 06:56:36PM -0500, Daniel Jacobowitz wrote:
> Thread_db, as things stand, does not work on core files.  Is preventing
> it from trying, and thus crashing GDB, really such a disruptive
> suggestion?

OK, that came out a little harsher than I really wanted it.  Sorry.

I'd like to apply this patch and then add an entry to TODO about
how it "should be done".  Is that better?

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

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

[Michael Snyder]

Daniel Jacobowitz wrote:
> 
> 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. 

Maybe so -- maybe not.  But at the moment we're talking about core
files.
Let's keep to one discussion at a time.

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

Assuming your MIPS remote target is multi-threaded, that would
definitely
confuse thread-db, yes.  But why would you want to do that?  

It seems like you are maybe trying to be more multi-arch than 
thread-db is designed for.  If the problem is that thread-db 
is not multi-arch enough, then let's address that problem.

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

Hold on -- I think we're having too many conversations at once.
The kernel doesn't know anything about glibc threads, which are
the only threads that thread-db is concerned with.

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

[Michael Snyder]

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.

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

[Michael Snyder]

Daniel Jacobowitz wrote:
> 
> On Thu, Dec 13, 2001 at 06:56:36PM -0500, Daniel Jacobowitz wrote:
> > Thread_db, as things stand, does not work on core files.  Is preventing
> > it from trying, and thus crashing GDB, really such a disruptive
> > suggestion?
> 
> OK, that came out a little harsher than I really wanted it.  Sorry.
> 
> I'd like to apply this patch and then add an entry to TODO about
> how it "should be done".  Is that better?

I'd really like to be able to look at the problem myself.
I have a lot invested in gdb's thread support on Linux, and
I don't have any way to reproduce the problem you're trying
to work around.  Could you provide a multi-threaded corefile
with corresponding symbol file for folks to experiment with?

If we agree to have your workaround checked in, and then later
decide that you've solved the problem the wrong way, then it will
be more painful to take out your workaround and make you revisit
the problem (after the bits have been flushed from your mental cache).  
Better we all agree on how to solve it first.

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

[Daniel Jacobowitz]

On Thu, Dec 13, 2001 at 05:26:47PM -0800, Michael Snyder wrote:
> Daniel Jacobowitz wrote:
> > 
> > On Thu, Dec 13, 2001 at 06:56:36PM -0500, Daniel Jacobowitz wrote:
> > > Thread_db, as things stand, does not work on core files.  Is preventing
> > > it from trying, and thus crashing GDB, really such a disruptive
> > > suggestion?
> > 
> > OK, that came out a little harsher than I really wanted it.  Sorry.
> > 
> > I'd like to apply this patch and then add an entry to TODO about
> > how it "should be done".  Is that better?
> 
> I'd really like to be able to look at the problem myself.
> I have a lot invested in gdb's thread support on Linux, and
> I don't have any way to reproduce the problem you're trying
> to work around.  Could you provide a multi-threaded corefile
> with corresponding symbol file for folks to experiment with?

I'll do that.  A binary is at:
  http://www.them.org/~drow/mtc.tgz
(The core file is a 23MB sparse file because of the unmapped user
stacks.  Careful where you unpack it.)

It'll be a couple of days before I can post the patch, at best; I'm
trying to sort out stopping threads right now.

This patch is based on something posted to linux-kernel several times
over the past year by different people; most recent (if my bad memory
serves me well) was by Elan Feingold.  His patch had a fatal bug, but
still produced working core files.

> If we agree to have your workaround checked in, and then later
> decide that you've solved the problem the wrong way, then it will
> be more painful to take out your workaround and make you revisit
> the problem (after the bits have been flushed from your mental cache).  
> Better we all agree on how to solve it first.

Sure.  But I have a fixed, very imminent deadline on this; the kernel
patch took up most of the time.  I'll try to spend time on a proper
solution later.

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

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

[Daniel Jacobowitz]

On Thu, Dec 13, 2001 at 05:22:02PM -0800, Michael Snyder wrote:
> 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?

Well, that's not actually something I need to do, but I'd like it to be
possible.  I only need for both native and cross-hosted debuggers to
both be able to get at the core files.  But as things stand now, if we
fix thread_db to be able to do so using lin-lwp, then the native and
cross debuggers will get at the threads using completely different
interfaces.  That worries me.

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

Hopefully, you'll be seeing them soon :)  I'll be publicly submitting
the patch if I find a less gross way to do it, and I'm trying.

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

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

[Daniel Jacobowitz]

On Thu, Dec 13, 2001 at 05:10:04PM -0800, Michael Snyder wrote:
> Hold on -- I think we're having too many conversations at once.
> The kernel doesn't know anything about glibc threads, which are
> the only threads that thread-db is concerned with.

Oversimplification there on my part.  At the moment, LinuxThreads is
the only package we've been asked to support for Linux thread
debugging; and for the at least short-term foreseeable future, it uses
a one-thread/one-kernel-task model.  Thus the kernel has everything I
need to debug them.

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

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

[Michael Snyder]

Daniel Jacobowitz wrote:
> 
> On Thu, Dec 13, 2001 at 05:26:47PM -0800, Michael Snyder wrote:
> > Daniel Jacobowitz wrote:
> > >
> > > On Thu, Dec 13, 2001 at 06:56:36PM -0500, Daniel Jacobowitz wrote:
> > > > Thread_db, as things stand, does not work on core files.  Is preventing
> > > > it from trying, and thus crashing GDB, really such a disruptive
> > > > suggestion?
> > >
> > > OK, that came out a little harsher than I really wanted it.  Sorry.
> > >
> > > I'd like to apply this patch and then add an entry to TODO about
> > > how it "should be done".  Is that better?
> >
> > I'd really like to be able to look at the problem myself.
> > I have a lot invested in gdb's thread support on Linux, and
> > I don't have any way to reproduce the problem you're trying
> > to work around.  Could you provide a multi-threaded corefile
> > with corresponding symbol file for folks to experiment with?
> 
> I'll do that.  A binary is at:
>   http://www.them.org/~drow/mtc.tgz
> (The core file is a 23MB sparse file because of the unmapped user
> stacks.  Careful where you unpack it.)

Oops -- Daniel, I think you sent the wrong corefile.  The one in
the tarball is only 1.4 megabytes, and was generated by "gdb ./lotsa_um
core".
Probably you ran gdb in the directory and it dropped core, overwriting
the corefile that you meant to send.  ;-(

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

[Daniel Jacobowitz]

On Fri, Dec 14, 2001 at 03:39:20PM -0800, Michael Snyder wrote:
> Daniel Jacobowitz wrote:
> > I'll do that.  A binary is at:
> >   http://www.them.org/~drow/mtc.tgz
> > (The core file is a 23MB sparse file because of the unmapped user
> > stacks.  Careful where you unpack it.)
> 
> Oops -- Daniel, I think you sent the wrong corefile.  The one in
> the tarball is only 1.4 megabytes, and was generated by "gdb ./lotsa_um
> core".
> Probably you ran gdb in the directory and it dropped core, overwriting
> the corefile that you meant to send.  ;-(

<falls over laughing>

Yes, so I did.  Oops.  I'm absolutely bewildered as to how that
happened - since the core file in that directory on my desktop is the
right one, and older than the tarfile I made!

Please look at http://www.them.org/~drow/mtc2.tgz, which is the proper
core.

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

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

[Andrew Cagney]

> On Thu, Dec 13, 2001 at 05:10:04PM -0800, Michael Snyder wrote:
> 
>> Hold on -- I think we're having too many conversations at once.
>> The kernel doesn't know anything about glibc threads, which are
>> the only threads that thread-db is concerned with.
> 
> 
> Oversimplification there on my part.  At the moment, LinuxThreads is
> the only package we've been asked to support for Linux thread
> debugging; and for the at least short-term foreseeable future, it uses
> a one-thread/one-kernel-task model.  Thus the kernel has everything I
> need to debug them.


We?  Just to clarify something is that a royal wee?

Andrew

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

[Daniel Jacobowitz]

On Fri, Dec 14, 2001 at 09:12:36PM -0500, Andrew Cagney wrote:
> >On Thu, Dec 13, 2001 at 05:10:04PM -0800, Michael Snyder wrote:
> >
> >>Hold on -- I think we're having too many conversations at once.
> >>The kernel doesn't know anything about glibc threads, which are
> >>the only threads that thread-db is concerned with.
> >
> >
> >Oversimplification there on my part.  At the moment, LinuxThreads is
> >the only package we've been asked to support for Linux thread
> >debugging; and for the at least short-term foreseeable future, it uses
> >a one-thread/one-kernel-task model.  Thus the kernel has everything I
> >need to debug them.
> 
> 
> We?  Just to clarify something is that a royal wee?

Sorry, that's a corporate we.  I'm working on this for a customer
contract.

Just about equally shortsighted of a we, though.

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

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

[Andrew Cagney]

> 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?
> 
> 
> Well, that's not actually something I need to do, but I'd like it to be
> possible.  I only need for both native and cross-hosted debuggers to
> both be able to get at the core files.  But as things stand now, if we
> fix thread_db to be able to do so using lin-lwp, then the native and
> cross debuggers will get at the threads using completely different
> interfaces.  That worries me.


At a technical level, it would mean making the thread:lwp mapping 
library multi-arch.  I think Michael gave a good summary - that isn't a 
free lunch.  (1)

Returning to the problem at hand though,

If you build --target=mips-unknown-linux-gnu does the resultant GDB 
include the native thread-db code?  Surely it doesn't since, as you 
point out, it can't work.  For the moment, would only be able to display 
threads, just the raw LWPs.

Hmm, perhaps it is a native GDB looking at a threaded core file?  In 
that case, yes the thread-db should drop its self on top.  If that is 
causing an internal error then there is something messed up that should 
be fixed.

Andrew

(1) The unixware thread code is a prototype of this sort of thing.  I 
say prototype since it really needs a proper target stack.

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

[Andrew Cagney]

> Hmm, perhaps it is a native GDB looking at a threaded core file?  In that case, yes the thread-db should drop its self on top.  If that is causing an internal error then there is something messed up that should be fixed.


PS:

Something I've wondered about is a command of some sort to tell GDB to 
not let the thread target interceed the ptrace / core / procfs / remote 
target so that, selectively the user could debug either the raw or the 
abstracted threaded target.

As a second mechanism, a way of moving between the threaded and ptrace / 
... target stratum.

Andrew

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

[Daniel Jacobowitz]

On Fri, Dec 14, 2001 at 09:31:10PM -0500, Andrew Cagney wrote:
> >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?
> >
> >
> >Well, that's not actually something I need to do, but I'd like it to be
> >possible.  I only need for both native and cross-hosted debuggers to
> >both be able to get at the core files.  But as things stand now, if we
> >fix thread_db to be able to do so using lin-lwp, then the native and
> >cross debuggers will get at the threads using completely different
> >interfaces.  That worries me.
> 
> 
> At a technical level, it would mean making the thread:lwp mapping 
> library multi-arch.  I think Michael gave a good summary - that isn't a 
> free lunch.  (1)
> 
> Returning to the problem at hand though,
> 
> If you build --target=mips-unknown-linux-gnu does the resultant GDB 
> include the native thread-db code?  Surely it doesn't since, as you 
> point out, it can't work.  For the moment, would only be able to display 
> threads, just the raw LWPs.

Indeed, it doesn't include thread-db.  It displays only the raw LWPs,
which suffices in the present model.

> Hmm, perhaps it is a native GDB looking at a threaded core file?  In 
> that case, yes the thread-db should drop its self on top.  If that is 
> causing an internal error then there is something messed up that should 
> be fixed.

Yes, that's where the internal error is.  They're based on the fact
that thread-db tries to enable event reporting, as best I can tell.

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

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

[Andrew Cagney]

> Hmm, perhaps it is a native GDB looking at a threaded core file?  In 
>> that case, yes the thread-db should drop its self on top.  If that is 
>> causing an internal error then there is something messed up that should 
>> be fixed.
> 
> 
> Yes, that's where the internal error is.  They're based on the fact
> that thread-db tries to enable event reporting, as best I can tell.


Sounds like that is the bug to fix.  Enabling event reporting probably 
doesn't make much sense when the target is lifeless.

enjoy,
Andrew

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

[Daniel Jacobowitz]

On Sat, Dec 15, 2001 at 12:15:58PM -0500, Andrew Cagney wrote:
> >Hmm, perhaps it is a native GDB looking at a threaded core file?  In 
> >>that case, yes the thread-db should drop its self on top.  If that is 
> >>causing an internal error then there is something messed up that should 
> >>be fixed.
> >
> >
> >Yes, that's where the internal error is.  They're based on the fact
> >that thread-db tries to enable event reporting, as best I can tell.
> 
> 
> Sounds like that is the bug to fix.  Enabling event reporting probably 
> doesn't make much sense when the target is lifeless.

I was about to try a patch for this when I realized that my primary
objection still holds.

This only works if you're debugging on a very similar host to the one
the core was dumped on.  If you've got, say, a glibc 2.1.3 host and are
looking at a glibc 2.2.3 core... well, you can provide target libraries
and make GDB use those, but there's no way to provide a cross
libthread_db.

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.

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

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

[Andrew Cagney]

> This only works if you're debugging on a very similar host to the one
> the core was dumped on.  If you've got, say, a glibc 2.1.3 host and are
> looking at a glibc 2.2.3 core... well, you can provide target libraries
> and make GDB use those, but there's no way to provide a cross
> libthread_db.


Yep.


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

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.

Andrew

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

[Daniel Jacobowitz]

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

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

[Daniel Jacobowitz]

On Thu, Dec 13, 2001 at 10:57:27AM -0800, Andrew Cagney wrote:
> >This patch fixes a really frustrating internal error when you open the
> >coredump of a multithreaded application.  Depending on your kernel, either
> >the core has threads (corefile.c supports this just fine) or it doesn't. 
> >Neither way will opening libthread_db work right.

corelow.c, rather.

> Daniel, can you explain the problem?  Thread-db should work on core 
> files (or realize it is silly and not open its self).

Right now, even after the event reporting issues, thread-db will not
work with core files.  The problem is that corefile.c adds the threads
to the thread list itself - and then thread_db finds them all and adds
them again.  One or the other needs to go.  If both try to add the
threads they'll step all over each other.

My instinct was "there is support in corefile-specific code for
handling threads.  It works just fine; use it."  It's been there since
1993.  Does it have any current consumers?  I think it must, since
Kevin touched it in May and mentioned some sort of regressions.  But
Linux has never produced these before and Solaris has its own handling. 
Does AIX maybe?

Since the overwhelming response seems to be that thread-db should be
doing this, and I can't make that happen without gutting corelow and I
have no idea what platforms that use that support, I'm going to leave
this alone unless someone else has a good idea.

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

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

[Kevin Buettner]

On Dec 16,  8:56pm, Daniel Jacobowitz wrote:

> My instinct was "there is support in corefile-specific code for
> handling threads.  It works just fine; use it."  It's been there since
> 1993.  Does it have any current consumers?  I think it must, since
> Kevin touched it in May and mentioned some sort of regressions.

I explained this in:

	http://sources.redhat.com/ml/gdb-patches/2001-04/msg00279.html

Here's the relevant bit:

    In addition to the renaming of identifiers, I also performed a type
    analysis and introduced calls to PIDGET (which is an existing macro
    which extracts a pid from a combined pid/tid) in cases where a pid
    was needed and calls to pid_to_ptid in cases where a pid needed to
    be converted into one of the combined objects.  I ran into two
    problems with the current representation:

	[problem one elided]

	- Second, I saw some regressions on Solaris due to the fact that
	  corelow.c was storing some corefile thread identifiers
	  in inferior_pid.  On Solaris 8, more than 16 bits are needed to
	  represent these identifiers.  For this case, I introduced some
	  #ifdefs in corelow.c which use inferior_ptid (renamed from
	  inferior_pid) "as is" without any masking.  I plan to eliminate
	  these ifdefs as part of phase 3.  (Or I could even do it as a
	  phase 4, if desired.)

[I'm wondering if there's a better place (than my patch email) to
describe this sort of thing.  Our current ChangeLog style doesn't
really accomodate it.  Also, I think adding something like the above
as a comment to the code would needlessly clutter it.  Is there anywhere
else it could go?]

Anyway, I think the above also addresses your question about current
consumers.

Kevin

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

[Daniel Jacobowitz]

On Sun, Dec 16, 2001 at 10:30:38PM -0700, Kevin Buettner wrote:
> On Dec 16,  8:56pm, Daniel Jacobowitz wrote:
> 
> > My instinct was "there is support in corefile-specific code for
> > handling threads.  It works just fine; use it."  It's been there since
> > 1993.  Does it have any current consumers?  I think it must, since
> > Kevin touched it in May and mentioned some sort of regressions.

> 	- Second, I saw some regressions on Solaris due to the fact that
> 	  corelow.c was storing some corefile thread identifiers
> 	  in inferior_pid.  On Solaris 8, more than 16 bits are needed to
> 	  represent these identifiers.  For this case, I introduced some
> 	  #ifdefs in corelow.c which use inferior_ptid (renamed from
> 	  inferior_pid) "as is" without any masking.  I plan to eliminate
> 	  these ifdefs as part of phase 3.  (Or I could even do it as a
> 	  phase 4, if desired.)

OK, Solaris uses corelow.  I didn't realize that.  Thanks.

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

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

[Michael Snyder]

Daniel Jacobowitz wrote:
> 
> On Fri, Dec 14, 2001 at 03:39:20PM -0800, Michael Snyder wrote:
> > Daniel Jacobowitz wrote:
> > > I'll do that.  A binary is at:
> > >   http://www.them.org/~drow/mtc.tgz
> > > (The core file is a 23MB sparse file because of the unmapped user
> > > stacks.  Careful where you unpack it.)
> >
> > Oops -- Daniel, I think you sent the wrong corefile.  The one in
> > the tarball is only 1.4 megabytes, and was generated by "gdb ./lotsa_um
> > core".
> > Probably you ran gdb in the directory and it dropped core, overwriting
> > the corefile that you meant to send.  ;-(
> 
> <falls over laughing>
> 
> Yes, so I did.  Oops.  I'm absolutely bewildered as to how that
> happened - since the core file in that directory on my desktop is the
> right one, and older than the tarfile I made!
> 
> Please look at http://www.them.org/~drow/mtc2.tgz, which is the proper
> core.

That file seems to be "not found".

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

[Daniel Jacobowitz]

On Mon, Dec 17, 2001 at 11:36:06AM -0800, Michael Snyder wrote:
> Daniel Jacobowitz wrote:
> > 
> > On Fri, Dec 14, 2001 at 03:39:20PM -0800, Michael Snyder wrote:
> > > Daniel Jacobowitz wrote:
> > > > I'll do that.  A binary is at:
> > > >   http://www.them.org/~drow/mtc.tgz
> > > > (The core file is a 23MB sparse file because of the unmapped user
> > > > stacks.  Careful where you unpack it.)
> > >
> > > Oops -- Daniel, I think you sent the wrong corefile.  The one in
> > > the tarball is only 1.4 megabytes, and was generated by "gdb ./lotsa_um
> > > core".
> > > Probably you ran gdb in the directory and it dropped core, overwriting
> > > the corefile that you meant to send.  ;-(
> > 
> > <falls over laughing>
> > 
> > Yes, so I did.  Oops.  I'm absolutely bewildered as to how that
> > happened - since the core file in that directory on my desktop is the
> > right one, and older than the tarfile I made!
> > 
> > Please look at http://www.them.org/~drow/mtc2.tgz, which is the proper
> > core.
> 
> That file seems to be "not found".

*sigh* mtc2.tar.gz, or that link will work now.  Either way.  Sorry.

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

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

[Michael Snyder]

Daniel Jacobowitz wrote:
> 
> This patch fixes a really frustrating internal error when you open the
> coredump of a multithreaded application.  Depending on your kernel, either
> the core has threads (corefile.c supports this just fine) or it doesn't.
> Neither way will opening libthread_db work right.
> 
> This patch isn't quite complete, because strange things happen when you
> connect to a remote target too.  But fixing that requires a little more
> fiddling.
> 
> Is this OK?

Daniel, sorry for the delay in getting back to you on this.
Now that I've had a chance to think about it, I agree that
this is the right thing to do.  Only I'd like to make it
a separate "if" and just goto quit -- since it is not 
related to the "if" that's in there now.  Is that OK
with you?

If you want you can just check in your patch as is, 
and I'll make mine as a separate change.

Michael

> 
> --
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer
> 
> 2001-12-13  Daniel Jacobowitz  <drow@mvista.com>
> 
>         * thread-db.c (thread_db_new_objfile): Don't use thread_db on
>         corefiles.
> 
> Index: thread-db.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/thread-db.c,v
> retrieving revision 1.18
> diff -u -r1.18 thread-db.c
> --- thread-db.c 2001/10/13 15:04:02     1.18
> +++ thread-db.c 2001/12/13 16:43:08
> @@ -482,7 +482,9 @@
>  {
>    td_err_e err;
> 
> -  if (objfile == NULL)
> +  /* Don't attempt to use thread_db on targets which can not run
> +     (core files).  */
> +  if (objfile == NULL || !target_has_execution)
>      {
>        /* All symbols have been discarded.  If the thread_db target is
>           active, deactivate it now.  */

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

[Daniel Jacobowitz]

On Thu, Jan 03, 2002 at 05:06:55PM -0800, Michael Snyder wrote:
> Daniel Jacobowitz wrote:
> > 
> > This patch fixes a really frustrating internal error when you open the
> > coredump of a multithreaded application.  Depending on your kernel, either
> > the core has threads (corefile.c supports this just fine) or it doesn't.
> > Neither way will opening libthread_db work right.
> > 
> > This patch isn't quite complete, because strange things happen when you
> > connect to a remote target too.  But fixing that requires a little more
> > fiddling.
> > 
> > Is this OK?
> 
> Daniel, sorry for the delay in getting back to you on this.
> Now that I've had a chance to think about it, I agree that
> this is the right thing to do.  Only I'd like to make it
> a separate "if" and just goto quit -- since it is not 
> related to the "if" that's in there now.  Is that OK
> with you?
> 
> If you want you can just check in your patch as is, 
> and I'll make mine as a separate change.

Well, I'mn not sure this is right.  It's a reasonable thing to attach
to a program, debug it live, then attach to a core of the same
program... at that point we need to go through the unpush_target steps
in just the same way as if the objfile was discarded, right?

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

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

[Michael Snyder]

Daniel Jacobowitz wrote:
> 
> On Thu, Jan 03, 2002 at 05:06:55PM -0800, Michael Snyder wrote:
> > Daniel Jacobowitz wrote:
> > >
> > > This patch fixes a really frustrating internal error when you open the
> > > coredump of a multithreaded application.  Depending on your kernel, either
> > > the core has threads (corefile.c supports this just fine) or it doesn't.
> > > Neither way will opening libthread_db work right.
> > >
> > > This patch isn't quite complete, because strange things happen when you
> > > connect to a remote target too.  But fixing that requires a little more
> > > fiddling.
> > >
> > > Is this OK?
> >
> > Daniel, sorry for the delay in getting back to you on this.
> > Now that I've had a chance to think about it, I agree that
> > this is the right thing to do.  Only I'd like to make it
> > a separate "if" and just goto quit -- since it is not
> > related to the "if" that's in there now.  Is that OK
> > with you?
> >
> > If you want you can just check in your patch as is,
> > and I'll make mine as a separate change.
> 
> Well, I'mn not sure this is right.  It's a reasonable thing to attach
> to a program, debug it live, then attach to a core of the same
> program... at that point we need to go through the unpush_target steps
> in just the same way as if the objfile was discarded, right?

Umm... I had to think about this, but no.  You can't debug a corefile
until you kill or detach from the process that you're already debugging.
When you kill or detach, that ought to take care of the unpush.

I think we are going to uncover some problems as we go, which we will
then have to take care of, but for the moment I do believe that this
is the right thing to do.

Michael

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

[Michael Snyder]

Daniel Jacobowitz wrote:
> 
> On Thu, Jan 03, 2002 at 05:06:55PM -0800, Michael Snyder wrote:
> > Daniel Jacobowitz wrote:
> > >
> > > This patch fixes a really frustrating internal error when you open the
> > > coredump of a multithreaded application.  Depending on your kernel, either
> > > the core has threads (corefile.c supports this just fine) or it doesn't.
> > > Neither way will opening libthread_db work right.
> > >
> > > This patch isn't quite complete, because strange things happen when you
> > > connect to a remote target too.  But fixing that requires a little more
> > > fiddling.
> > >
> > > Is this OK?
> >
> > Daniel, sorry for the delay in getting back to you on this.
> > Now that I've had a chance to think about it, I agree that
> > this is the right thing to do.  Only I'd like to make it
> > a separate "if" and just goto quit -- since it is not
> > related to the "if" that's in there now.  Is that OK
> > with you?
> >
> > If you want you can just check in your patch as is,
> > and I'll make mine as a separate change.
> 
> Well, I'mn not sure this is right.  It's a reasonable thing to attach
> to a program, debug it live, then attach to a core of the same
> program... at that point we need to go through the unpush_target steps
> in just the same way as if the objfile was discarded, right?

Hmmmm... I don't quite understand why, but your version does seem
to work better.  Let's use it for now.  Check it in?

Michael

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

[Daniel Jacobowitz]

On Fri, Jan 04, 2002 at 05:23:35PM -0800, Michael Snyder wrote:
> Hmmmm... I don't quite understand why, but your version does seem
> to work better.  Let's use it for now.  Check it in?

Done.  We can investigate the gory details later.

I'm thinking about also moving this to the branch - but I'm going to
have a lot of branch patches, so I'll do them all together next week
when I can test them all.

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