This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]