[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