From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13892 invoked by alias); 4 Sep 2005 15:48:22 -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 13849 invoked by uid 22791); 4 Sep 2005 15:48:15 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 04 Sep 2005 15:48:15 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1EBwiw-0000dq-Cl; Sun, 04 Sep 2005 11:48:02 -0400 Date: Sun, 04 Sep 2005 15:48:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: uweigand@de.ibm.com, manjo@austin.ibm.com, gdb-patches@sources.redhat.com Subject: Re: [RFC/RFA] Target vectors for native Linux targets Message-ID: <20050904154802.GA1978@nevyn.them.org> Mail-Followup-To: Mark Kettenis , uweigand@de.ibm.com, manjo@austin.ibm.com, gdb-patches@sources.redhat.com References: <200508211328.j7LDSVhH003835@53v30g15.boeblingen.de.ibm.com> <200508211520.j7LFKx77016199@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200508211520.j7LFKx77016199@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-09/txt/msg00022.txt.bz2 Comments on the actual patch to follow, separately. On Sun, Aug 21, 2005 at 05:20:59PM +0200, Mark Kettenis wrote: > > From: Ulrich Weigand > > Date: Sun, 21 Aug 2005 15:28:31 +0200 (CEST) > > > > Mark Kettenis wrote: > > > > > Hmm, it would be preferable to have it the other way around, since > > > that would make eliminating the nm-linux.h files, but I can see why > > > you did it this way. In the end we might just define USE_LINUX_TARGET > > > if GDB_NM_FILE isn't defined. So it's not really important. I've > > > added some more comments on the patch inline. > > > > I guess we could make a config/nm-new-linux.h or something -- that > > would be a (temporary) new nm file, but would allow to remove the > > per-platform Linux nm files as platforms are converted over ... > > Don't bother. All the cruft in there has to go away eventually. > Making it more cruftier in the meantime isn't a problem. Half of Mark's followup comments were about the mechanism to do this a target at a time. Let's not. My original patch covered every single GNU/Linux target and I tested more than half of them. I don't know if I'll redo the mammoth testing sequence this time, but only a handful (i386, ia64, s390, maybe sparc? don't recall) were particularly unique. I have access to the great majority of GNU/Linux targets supported by GDB for testing. > > > Daniels earlier attempt had linux_target accept a `struct target_ops > > > *' as an argument to serve as an alternative for a plain > > > inf_ptrace_target(). I thought that was necessary for i386 and sparc > > > Linux targets, but I think I've convinced myself that it isn't. My goal was not just to start using inf_ptrace_target, but to unify the single-threaded and multi-threaded target vectors. The multi-threaded target provides its own to_resume which calls child_resume. i386-linux-nat.c provides its own child_resume which works around an old Linux kernel bug. In Ulrich's patch, the target could modify linux_ops, which is exposed to it by the return value of linux_target (). This would cease to work when linux_target started to return a multithreaded target. But the way I did it was pretty ugly and Andrew's suggestion in the followup discussion was much nicer (barring naming); just provide a hook in linux-nat.h to implement the same functionality differently. And I've got some other ideas on how to neaten it up, though they may not turn out to be useful. I've learned some interesting things from reading Ulrich's patch. I'm going to stitch the two together this afternoon. > > Since you can always override the target functions afterwards, > > I'm not sure why this would be necessary ... > > I think Daniels earlier patch did things a little bit differently, > eliminating the Linux pseudo-LWP layer. That made overriding things > afterwards more difficult. All the more reason to go with your patch > instead of reviving Daniels old one. There's a lot of complexity and target-stack-violation caused by the fact that the GNU/Linux "child" stratum can't handle multithreaded applications. It really needs to die. -- Daniel Jacobowitz CodeSourcery, LLC