From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28457 invoked by alias); 3 Jun 2003 20:03:08 -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 28351 invoked from network); 3 Jun 2003 20:03:05 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 3 Jun 2003 20:03:05 -0000 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id C35E7800021; Tue, 3 Jun 2003 16:03:04 -0400 (EDT) Message-ID: <3EDCFEF8.30703@redhat.com> Date: Tue, 03 Jun 2003 20:03:00 -0000 From: "J. Johnston" Organization: Red Hat Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Snyder Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: Patch for corefile support References: <3E35BB3A.2020003@redhat.com> <3EDBA406.7F38D18E@redhat.com> Content-Type: multipart/mixed; boundary="------------010409090504050909080001" X-SW-Source: 2003-06/txt/msg00134.txt.bz2 This is a multi-part message in MIME format. --------------010409090504050909080001 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1307 Michael Snyder wrote: > "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 > > Thanks Michael. The attached patch has been checked in with the following ChangeLog. 2003-06-03 Jeff Johnston * thread-db.c (thread_db_mourn_inferior): Unpush thread target layer if not dealing with a statically-linked threaded program. -- Jeff J. --------------010409090504050909080001 Content-Type: text/plain; name="thread-db.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="thread-db.patch" Content-length: 842 Index: thread-db.c =================================================================== RCS file: /cvs/src/src/gdb/thread-db.c,v retrieving revision 1.31 diff -u -r1.31 thread-db.c --- thread-db.c 8 May 2003 22:33:14 -0000 1.31 +++ thread-db.c 3 Jun 2003 20:00:37 -0000 @@ -1011,6 +1011,18 @@ proc_handle.pid = 0; target_beneath->to_mourn_inferior (); + + /* Detach thread_db target ops if not dealing with a statically + linked threaded program. This allows a corefile to be debugged + after finishing debugging of a threaded program. At present, + debugging a statically-linked threaded program is broken, but + the check is added below in the event that it is fixed in the + future. */ + if (!keep_thread_db) + { + unpush_target (&thread_db_ops); + using_thread_db = 0; + } } static int --------------010409090504050909080001--