From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 723 invoked by alias); 6 Dec 2004 14:41:38 -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 693 invoked from network); 6 Dec 2004 14:41:31 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 6 Dec 2004 14:41:31 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1CbK3K-0003mW-Bd; Mon, 06 Dec 2004 09:41:26 -0500 Date: Mon, 06 Dec 2004 14:43:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] Use target vector inheritance for GNU/Linux Message-ID: <20041206144125.GA14232@nevyn.them.org> Mail-Followup-To: Mark Kettenis , gdb-patches@sources.redhat.com References: <20041205184549.GA19814@nevyn.them.org> <200412061410.iB6EAgpA019134@juw15.nfra.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200412061410.iB6EAgpA019134@juw15.nfra.nl> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-12/txt/msg00161.txt.bz2 On Mon, Dec 06, 2004 at 03:10:42PM +0100, Mark Kettenis wrote: > A new function, linux_target, is added to linux-nat.c. Then any GNU/Linux > target can call it, and pass the result to add_target - after specializing > whatever methods it needs to. Sometimes it's necessary to specialize a > method between inf_ptrace_target and linux_target, so it accepts an optional > argument. > > Yes, indeed, in particual the way the various Linux ports deal with > reading and writing registers is really different. > > This wouldn't be necessary if all target methods took a > target_ops parameter, so they could call the overridden method. > > I don't think so. The target_ops parameter is intended to provide a > way for strata to "inherit" stuff from other strata (i.e. the > core_stratum inheriting the to_xfer_partial method from the > file_stratum). Here we're talking about inheriting stuff from a > prototype vector within a single stratum. Right now the only thing I need this for is to find a method in this target and stratum. i386-linux-nat.c provides to_resume, and linux-nat.c used to call child_resume directly (because it can't use target_resume, which would go through thread-db and back to linux-nat again). So I have to somehow pass the pointer to the i386 resume to linux-nat.c, and this seemed like the right way. So from a short-term, literal perspective, what I wrote is correct: the only reason that there is a target_ops argument to linux_target would be unnecessary if there were more target methods that took their own target_ops argument. Long-term, with the target_ops arguments added, I'm really not sure. The only difference would be whether the i386-linux version calls or is called by the generic GNU/Linux version; and for all the examples I've looked at, it doesn't matter. > I've tested this patch with the full testsuite on x86_64-linux and > i386-linux, partial testsuite on ia64-linux [it gets hung up in an > infinite loop in sigaltstack.exp with or without the patch], and smoke > testing on s390x [the machine I was using didn't have expect]. > > I'll try to test & cleanup sparc and possibly sparc64. Thank you very much! Randolph has also tested hppa-linux for me. > Comments? Proofreading? I'm going to let this sit for a couple of days, > because (while mechanical) it's very large - I think I got everything, but > since I don't have the resources to test on every single GNU/Linux native > target, I can't be sure. > > I'm just wondering whether the saved_xxx variables should be called > linux_saved_xxx instead. Probably not... Possibly, by analogy to the methods using them. I can rename if you'd prefer. -- Daniel Jacobowitz