From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1443 invoked by alias); 2 Jun 2003 19:22:49 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 1410 invoked from network); 2 Jun 2003 19:22:49 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 2 Jun 2003 19:22:49 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h52JMmH22914 for ; Mon, 2 Jun 2003 15:22:48 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h52JMlT32264 for ; Mon, 2 Jun 2003 15:22:47 -0400 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h52JMl022858; Mon, 2 Jun 2003 12:22:47 -0700 Message-ID: <3EDBA406.7F38D18E@redhat.com> Date: Mon, 02 Jun 2003 19:22:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: "J. Johnston" CC: gdb-patches@sources.redhat.com Subject: Re: RFA: Patch for corefile support References: <3E35BB3A.2020003@redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2003-06/txt/msg00086.txt.bz2 "J. Johnston" wrote: > > 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? > > -- Jeff J. Hi Jeff, After reviewing the discussion, why don't you add a test for "keep_thread_db" as suggested by Mark, and check this in? Perhaps with a comment explaining that the debugging of statically-linked threaded programs is currently broken, but this will preserve sanity in case it is ever fixed. Michael > > ------------------------------------------------------------------------------- > Index: thread-db.c > =================================================================== > RCS file: /cvs/src/src/gdb/thread-db.c,v > retrieving revision 1.28 > diff -u -r1.28 thread-db.c > --- thread-db.c 14 Jan 2003 00:49:04 -0000 1.28 > +++ thread-db.c 27 Jan 2003 22:58:58 -0000 > @@ -1007,6 +1007,11 @@ > proc_handle.pid = 0; > > target_beneath->to_mourn_inferior (); > + > + /* Detach thread_db target ops. The thread_db_new_objfile routine > + will reattach them later if needed. */ > + unpush_target (&thread_db_ops); > + using_thread_db = 0; > } > > static int