From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10160 invoked by alias); 13 Sep 2004 19:26:52 -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 10152 invoked from network); 13 Sep 2004 19:26:51 -0000 Received: from unknown (HELO caduceus.fm.intel.com) (192.55.52.25) by sourceware.org with SMTP; 13 Sep 2004 19:26:51 -0000 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i8DJQoxi003981; Mon, 13 Sep 2004 19:26:50 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i8DJR0QI030821; Mon, 13 Sep 2004 19:27:10 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004091312262821498 ; Mon, 13 Sep 2004 12:26:28 -0700 Received: from fmsmsx403.amr.corp.intel.com ([132.233.42.207]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Sep 2004 12:26:28 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rfa] Assume thread-db loaded over a live process Date: Mon, 13 Sep 2004 19:26:00 -0000 Message-ID: <331AD7BED1579543AD146F5A1A44D5250418593A@fmsmsx403.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Howell, David P" To: "Michael Snyder" , "Andrew Cagney" Cc: X-OriginalArrivalTime: 13 Sep 2004 19:26:28.0353 (UTC) FILETIME=[91012710:01C499C7] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-SW-Source: 2004-09/txt/msg00211.txt.bz2 As I recall from 5.3 this was necessary due to libthread_db=20 using the /proc access libraries to get info from the inferior;=20 it would require an alternate implementation for similar core=20 file access, it wasn't there then and so the guard was necessary. It would be nice if this were fixed.=20 Thanks, Dave Howell These are my opinions and not official opinions of Intel Corp. =20 David Howell Intel Corporation Telco Server Development Server Products Division Voice: (803) 216-2359 Fax: (803) 216-2178 =20 Intel Corporation Columbia Design Center, CBA-1 100 Center Point Circle, Suite 210 Columbia, SC 29210 =20 david.p.howell@intel.com =20 -----Original Message----- From: gdb-patches-owner@sources.redhat.com [mailto:gdb-patches-owner@sources.redhat.com] On Behalf Of Michael Snyder Sent: Monday, September 13, 2004 2:44 PM To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [rfa] Assume thread-db loaded over a live process Andrew Cagney wrote: > Hello, >=20 > This patch changes: >=20 > - /* We can only poke around if there actually is a child process. > - If there is no child process alive, postpone the steps below > - until one has been created. */ > - if (proc_handle.pid !=3D 0) > - { > - enable_thread_event_reporting (); > - thread_db_find_new_threads (); > - } > + enable_thread_event_reporting (); > + thread_db_find_new_threads (); >=20 > this code is only executed when there is a child process so the guard=20 > isn't needed. Tested on GNU/Linux, no change in test results. >=20 > ok? From memory, I think this code was to guard against the corefile case. When you load a corefile, you may call thread_db_new_objfile, but you won't have a child process. Is that no longer the case? Does loading a corefile no longer cause this function to be called?