From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8328 invoked by alias); 12 Jan 2006 06:09:45 -0000 Received: (qmail 8320 invoked by uid 22791); 12 Jan 2006 06:09:45 -0000 X-Spam-Check-By: sourceware.org Received: from smtp5.wanadoo.fr (HELO smtp5.wanadoo.fr) (193.252.22.26) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 12 Jan 2006 06:09:44 +0000 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0503.wanadoo.fr (SMTP Server) with ESMTP id 16E451C00105 for ; Thu, 12 Jan 2006 07:09:42 +0100 (CET) Received: from takamaka.act-europe.fr (AStDenis-105-1-26-63.w81-248.abo.wanadoo.fr [81.248.238.63]) by mwinf0503.wanadoo.fr (SMTP Server) with ESMTP id A575F1C0018A for ; Thu, 12 Jan 2006 07:09:41 +0100 (CET) X-ME-UUID: 20060112060941677.A575F1C0018A@mwinf0503.wanadoo.fr Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 4310847E7B; Thu, 12 Jan 2006 10:09:39 +0400 (RET) Date: Thu, 12 Jan 2006 06:09:00 -0000 From: Joel Brobecker To: gdb-patches@sources.redhat.com Subject: [RFC] New function find_target_at_stratum() ? Message-ID: <20060112060939.GK676@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00122.txt.bz2 Hello, While learning a bit more about the target vector and the target stack, and how it is used, I noticed that two files, sol-thread.c and uw-thread.c make an explicit reference to the procfs_ops target vector. Looking at the code, the idea is to implement one target method at the thread level by first using the same method at the process level and then by performing the necessary operations to handle threads. For instance: static void sol_thread_attach (char *args, int from_tty) { procfs_ops.to_attach (args, from_tty); /* Must get symbols from shared libraries before libthread_db can run! */ solib_add (NULL, from_tty, (struct target_ops *) 0, auto_solib_add); [...] } This is really nit-picking, but I think we can get rid of these explicit references and then make procfs_ops static. The way to do this would be to change the reference to procfs_ops by a function that would return the target vector at the process level. Ie: find_target_ops_at_stratum (process_stratum).to_attach (args, from_tty); This means adding a new function in target.h/target.c. To be complete, I think the current public interface already allows us to find the target vector at any stratum. Just by using current_target and find_target_beneath(). I just thought that the new proposed function might be of general interest? Thoughts? -- Joel