From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-27775-listarch-gdb-patches=sources.redhat.com@sources.redhat.com>
Received: (qmail 15346 invoked by alias); 10 Oct 2003 00:12:10 -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 15339 invoked from network); 10 Oct 2003 00:12:10 -0000
Received: from unknown (HELO mx1.redhat.com) (66.187.233.31)
  by sources.redhat.com with SMTP; 10 Oct 2003 00:12:10 -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 h9A0C9M05682
	for <gdb-patches@sources.redhat.com>; Thu, 9 Oct 2003 20:12:09 -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 h9A0C7D07613;
	Thu, 9 Oct 2003 20:12:08 -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 h9A0C7i13794;
	Thu, 9 Oct 2003 17:12:07 -0700
Message-ID: <3F85F957.30306@redhat.com>
Date: Fri, 10 Oct 2003 00:12:00 -0000
From: Michael Snyder <msnyder@redhat.com>
Organization: Red Hat, Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kevin Buettner <kevinb@redhat.com>
CC: Roland McGrath <roland@redhat.com>, Jim Blandy <jimb@redhat.com>,
   Daniel Jacobowitz <drow@mvista.com>, Elena Zannoni <ezannoni@redhat.com>,
   gdb-patches@sources.redhat.com
Subject: Re: unwind support for Linux 2.6 vsyscall DSO
References: <200310092220.h99MKXvN010506@magilla.sf.frob.com> <1031009224936.ZM14899@localhost.localdomain>
In-Reply-To: <1031009224936.ZM14899@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-SW-Source: 2003-10/txt/msg00336.txt.bz2

Kevin Buettner wrote:
> On Oct 9,  3:20pm, Roland McGrath wrote:
> 
> 
>>Kevin says:
>>
>>>I think that's what TARGET_CREATE_INFERIOR_HOOK is for.
>>
>>This is only called in the "run" case.  There is also
>>SOLIB_CREATE_INFERIOR_HOOK, but that is called only in the "run", "target
>>remote", and follow-exec cases AFAICT.  
>>
>>To reiterate, we need something that is called at the break-on-exec from
>>run, immediately after attach, immediately after loading a core file, and
>>after follow-exec breaks if that support is real.
> 
> 
> It may be possible that the existing mechanisms (either
> TARGET_CREATE_INFERIOR_HOOK or SOLIB_CREATE_INFERIOR_HOOK) are
> adequate, but simply not called from enough places.  If these
> must stay as they are, then we need some new hooks.  These days,
> we normally set these up as gdbarch methods.  For linux, such a
> method could be registered in the $arch-linux-tdep.c file.

History-man says, TARGET_CREATE_INFERIOR_HOOK was added in 1995,
specifically to fork-child.c, to allow somebody to get control
of the new child process just before execution of the first
instruction.  Seems like we would need a different hook for,
say, attach.