From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29655 invoked by alias); 22 Apr 2004 00:18:30 -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 29641 invoked from network); 22 Apr 2004 00:18:29 -0000 Received: from unknown (HELO localhost.redhat.com) (24.157.170.238) by sources.redhat.com with SMTP; 22 Apr 2004 00:18:29 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 115BB2B9D; Wed, 21 Apr 2004 20:18:19 -0400 (EDT) Message-ID: <40870F4A.4010009@gnu.org> Date: Thu, 22 Apr 2004 00:18:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Roland McGrath Cc: gdb-patches@sources.redhat.com Subject: Re: [KLUDGE PATCH] Linux vsyscall DSO support References: <200404082150.i38LoEcx010967@magilla.sf.frob.com> In-Reply-To: <200404082150.i38LoEcx010967@magilla.sf.frob.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-04/txt/msg00513.txt.bz2 >>> Last time this was discussed the observer was identified as the correct >>> mechanim for hooking this in. That's why I'm currently overhauling that >>> code. > > > Ok. I forget many things, but I think this is news to me. I remember sending an explicit e-mail, I suspect you didn't see it as your mailing address got trimmed part way through the thread :-( > I hadn't seen > the "observer" code before; I now see it's a simple facility for running a > list multiple hooks previously registered, so this is today's preferred > form of adding a new hook. Two questions remain for me: > > What is the new hook or hooks you plan to add? i.e., will it be a single > "look freshly at address space" hook, or separate hooks for "attached", > "exec'd", "opened core", etc? It matters little, unless we anticipate > future different situations that would also qualify as "look freshly at > address space" situations but aren't one of the three I listed. I think there should be a something like a "new_inferior" event that incorporates "run", "attach", and "corefile". As we've recently discovered, "run" is just a slight simplification of attach. (Because of some screwieness in how the target vector is [isn't] designed, a number of files will need to have the call added - that can be handled as identified). > Where is the right place to install our observer? My inclination is to add > linux-tdep.c to all the Linux targets as my strawman patch does, and have > an _initialize_linux_tdep function that registers the observers. Is that > what you are thinking as well? Guess so. The decsion to load one of these shlibs is really based solely on the presence of that AT_xxxx auxv entry and the observer gets to check that. Andrew