From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4053 invoked by alias); 8 Apr 2004 22:13:21 -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 4041 invoked from network); 8 Apr 2004 22:13:19 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.81.54.130) by sources.redhat.com with SMTP; 8 Apr 2004 22:13:19 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 4F435357B; Thu, 8 Apr 2004 14:50:15 -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 i38LoFOi010971; Thu, 8 Apr 2004 14:50:15 -0700 Received: (from roland@localhost) by magilla.sf.frob.com (8.12.9/8.12.9/Submit) id i38LoEcx010967; Thu, 8 Apr 2004 14:50:14 -0700 Date: Thu, 08 Apr 2004 22:13:00 -0000 Message-Id: <200404082150.i38LoEcx010967@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [KLUDGE PATCH] Linux vsyscall DSO support In-Reply-To: Andrew Cagney's message of Thursday, 8 April 2004 17:30:06 -0400 <4075C45E.50005@gnu.org> X-Windows: foiled again. X-SW-Source: 2004-04/txt/msg00198.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 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. 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? Thanks, Roland