From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-35772-listarch-gdb-patches=sources.redhat.com@sources.redhat.com>
Received: (qmail 30452 invoked by alias); 13 Sep 2004 18:44:27 -0000
Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-patches-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sources.redhat.com>
List-Help: <mailto:gdb-patches-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-patches-owner@sources.redhat.com
Received: (qmail 30444 invoked from network); 13 Sep 2004 18:44:26 -0000
Received: from unknown (HELO mx1.redhat.com) (66.187.233.31)
  by sourceware.org with SMTP; 13 Sep 2004 18:44:26 -0000
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8DIiQup014505
	for <gdb-patches@sources.redhat.com>; Mon, 13 Sep 2004 14:44:26 -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 i8DIiP716745;
	Mon, 13 Sep 2004 14:44:25 -0400
Received: from redhat.com (dhcp-172-16-25-160.sfbay.redhat.com [172.16.25.160])
	by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i8DIiOV11898;
	Mon, 13 Sep 2004 11:44:24 -0700
Message-ID: <4145EA88.2050401@redhat.com>
Date: Mon, 13 Sep 2004 18:44:00 -0000
From: Michael Snyder <msnyder@redhat.com>
Organization: Red Hat, Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.4.2) Gecko/20040301
MIME-Version: 1.0
To: Andrew Cagney <cagney@gnu.org>
CC: gdb-patches@sources.redhat.com
Subject: Re: [rfa] Assume thread-db loaded over a live process
References: <4145A745.6090603@gnu.org>
In-Reply-To: <4145A745.6090603@gnu.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-SW-Source: 2004-09/txt/msg00210.txt.bz2

Andrew Cagney wrote:
> Hello,
> 
> This patch changes:
> 
> -      /* 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 != 0)
> -       {
> -         enable_thread_event_reporting ();
> -         thread_db_find_new_threads ();
> -       }
> +      enable_thread_event_reporting ();
> +      thread_db_find_new_threads ();
> 
> this code is only executed when there is a child process so the guard 
> isn't needed.    Tested on GNU/Linux, no change in test results.
> 
> 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?