From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7432 invoked by alias); 9 Oct 2003 22:49:45 -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 7425 invoked from network); 9 Oct 2003 22:49:44 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 9 Oct 2003 22:49:44 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h99MnhM18165 for ; Thu, 9 Oct 2003 18:49:43 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h99Mnhc09919; Thu, 9 Oct 2003 18:49:43 -0400 Received: from localhost.localdomain (vpn50-39.rdu.redhat.com [172.16.50.39]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id h99MnfdT012135; Thu, 9 Oct 2003 18:49:41 -0400 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h99Mnaf14900; Thu, 9 Oct 2003 15:49:36 -0700 Date: Thu, 09 Oct 2003 22:49:00 -0000 From: Kevin Buettner Message-Id: <1031009224936.ZM14899@localhost.localdomain> In-Reply-To: Roland McGrath "Re: unwind support for Linux 2.6 vsyscall DSO" (Oct 9, 3:20pm) References: <200310092220.h99MKXvN010506@magilla.sf.frob.com> To: Roland McGrath , Jim Blandy Subject: Re: unwind support for Linux 2.6 vsyscall DSO Cc: Daniel Jacobowitz , Kevin Buettner , Elena Zannoni , gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-10/txt/msg00329.txt.bz2 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. > We also need to clear out the state that hook will set up. clear_solib > seems to be called at a reasonable time on the next "run", though only > SOLIB_RESTART is called in the follow-exec case and I'm not sure if > anything helpful is called to reset state before a new "attach". > > The hooks I need are "we've just seen a new address space for the first > time" and "scratch that, the address space is gone". I suppose actually > just the one suffices if it's never called extra times, so it just clears > the old and fetches the new every time. I think I had better go back and read past discussion. Kevin