From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27985 invoked by alias); 9 Oct 2003 22:20:37 -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 27970 invoked from network); 9 Oct 2003 22:20:35 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.81.54.130) by sources.redhat.com with SMTP; 9 Oct 2003 22:20:35 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 787FD357B; Thu, 9 Oct 2003 15:20:34 -0700 (PDT) Received: from magilla.sf.frob.com (localhost.localdomain [127.0.0.1]) by magilla.sf.frob.com (8.12.9/8.12.9) with ESMTP id h99MKYN2010510; Thu, 9 Oct 2003 15:20:34 -0700 Received: (from roland@localhost) by magilla.sf.frob.com (8.12.9/8.12.9/Submit) id h99MKXvN010506; Thu, 9 Oct 2003 15:20:33 -0700 Date: Thu, 09 Oct 2003 22:20:00 -0000 Message-Id: <200310092220.h99MKXvN010506@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Jim Blandy Cc: Daniel Jacobowitz , Kevin Buettner , Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: unwind support for Linux 2.6 vsyscall DSO In-Reply-To: Jim Blandy's message of , 9 October 2003 15:08:56 -0500 X-Shopping-List: (1) Fluent sandwiches (2) Gracious academic trash (3) Religious atomic commanders X-SW-Source: 2003-10/txt/msg00325.txt.bz2 > Daniel Jacobowitz writes: > > The problem with using SOLIB_ADD for this is that we can't SOLIB_ADD > > safely till we hit the dynamic linker breakpoint, but it would be > > _really_ nice to be able to load this object right after the inferior > > starts (and for static binaries, etc etc). How would you suggets we do > > that? > > Well, look, the whole association with SOLIB_ADD at all was just based > on the intuition that "Hey, this vsyscall thing is like a shared > library!" Nothing more profound than that. So if it turns out that > sticking with SOLIB_ADD makes things complicated, then it'd be much > better to just add calls to the core, attach, and run code, or > whereever else is appropriate, that does things exactly the way you > want. In the prior discussion I got the impression that SOLIB_ADD did happen early enough (right after the exec stop), and just got repeated more times later when there is actually anything in the dynamic linker's list. Is that not accurate? 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. 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. Thanks, Roland