From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17038 invoked by alias); 1 Feb 2004 20:23:20 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 17026 invoked from network); 1 Feb 2004 20:23:19 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 1 Feb 2004 20:23:19 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AnO7d-0005Dx-B8 for ; Sun, 01 Feb 2004 15:23:13 -0500 Date: Sun, 01 Feb 2004 20:23:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: Re: [RFC] TARGET_OBJECT_WCOOKIE Message-ID: <20040201202313.GA20053@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com References: <200402011702.i11H2HEZ000487@elgar.kettenis.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200402011702.i11H2HEZ000487@elgar.kettenis.dyndns.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-02/txt/msg00005.txt.bz2 On Sun, Feb 01, 2004 at 06:02:17PM +0100, Mark Kettenis wrote: > Actually the purpose of this RFC is twofold. > > First, I'd like to add a TARGET_OBJECT_WCOOKIE method to support the > StackGhost cookie on OpenBSD/sparc. This really is something > target-related rather than OS/ABI related. GDB will have to deal with > StackGhost when running non-OpenBSD binaries on an OpenBSD kernel. > Moreover, older OpenBSD kernels might not have StackGhost. Anyway, > are there objections to adding something like the attached patch? Not from me. > The second issue I'd like your opinion on is related to the patch. I > followed the example set by TARGET_OBJECT_UNWIND_TABLE in having a > macro (NATIVE_XFER_WCOOKIE) to invoke the native-specific function > that fetches the cookie. This macro would be defined in the nm.h > file, but wasn't it our goal to get rid of the nm.h file sooner rather > than later? Shouldn't we add another method for these kinds of hooks? > The obvious alternatives are: > > a) Use a public function pointer, which is initialized to some > do-nothing-and-return-minus-one function by default. This function > pointer would be overridden by some code in the appropraite *-nat.c > files. > > b) Use a private function pointer, and provide a function to set that > pointer, along the lines of inftarg_set_find_memory_regions(). > > Opinions? Personally, I think the -nat files should have a chance to edit child_ops, or provide their own version of child_ops. This would eliminate 90% of the gunk in nm* files which is checked in the various inf* files implementing child_ops. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer