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: Patch for corefile support



Daniel Jacobowitz wrote:
On Sat, Feb 01, 2003 at 02:22:02PM +0100, Mark Kettenis wrote:

"J. Johnston" <jjohnstn@redhat.com> writes:


The attached patch fixes a problem in gdb when a corefile is read in
after a multithreaded application has been debugged.  What happens is that
the thread-db and lin-lwp layers are still around and run into internal
errors.

The solution is simply to unpush the thread-db ops in its mourn_inferior
routine.  If a corefile gets loaded, there is no thread-db to interfere.
If another multi-threaded app gets loaded, the thread_db_new_objfile is
designed to bring back the thread-db layer as needed.

This fix solves another failure in the killed.exp testsuite as well.

Ok to commit?
Sorry, no.  AFAICT this will break debugging programs that are
statically linked against libpthread.  As a minimum, this code should
check keep_thread_db before unpushing the target, but even then, I'm
not sure whether this is really OK.

Programs statically linked against libpthread are already broken.  I
have a patch to fix it, but it's so gross that I haven't posted it; I
still can't think of a good way to do it.

Given the way GDB treats targets, we seem to be waffling; someone fixes
core file support and breaks static binaries, or vice versa.

So, is there a scenario where my patch would be wrong?  I am seeing what you
discussed.  Statically linked multi-threaded programs don't work with gdb
because we never set up the thread_db_ops layer to begin with
(thread_db_new_objfile never gets called with a non-null objfile with
the target_has_execution flag on).

-- Jeff J.


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