From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17184 invoked by alias); 13 Nov 2006 12:43:24 -0000 Received: (qmail 17170 invoked by uid 22791); 13 Nov 2006 12:43:21 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-vbr6.xs4all.nl (HELO smtp-vbr6.xs4all.nl) (194.109.24.26) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 13 Nov 2006 12:43:10 +0000 Received: from webmail.xs4all.nl (dovemail7.xs4all.nl [194.109.26.9]) by smtp-vbr6.xs4all.nl (8.13.8/8.13.8) with ESMTP id kADCg2Yw000429; Mon, 13 Nov 2006 13:42:07 +0100 (CET) (envelope-from mark.kettenis@xs4all.nl) Received: from 192.87.1.22 (SquirrelMail authenticated user sibelius) by webmail.xs4all.nl with HTTP; Mon, 13 Nov 2006 13:42:07 +0100 (CET) Message-ID: <22583.192.87.1.22.1163421727.squirrel@webmail.xs4all.nl> In-Reply-To: <200611131227.kADCRe28032402@d12av02.megacenter.de.ibm.com> References: <200611131227.kADCRe28032402@d12av02.megacenter.de.ibm.com> Date: Mon, 13 Nov 2006 12:43:00 -0000 Subject: Re: [RFA][3/5] New port: Cell BE SPU (the port itself) From: "Mark Kettenis" To: "Ulrich Weigand" Cc: "Daniel Jacobowitz" , "Mark Kettenis" , gdb-patches@sourceware.org User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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-11/txt/msg00097.txt.bz2 > Daniel Jacobowitz wrote: > > > On Sun, Nov 12, 2006 at 10:41:34PM +0100, Mark Kettenis wrote: > > > I think that what you really want is a Linux powerpc native > > configuration > > > that can debug both normal powerpc code and spu code. That'd mean > > adding > > > spu-linux-nat.c to config/powerpc/linux.mh. But I suppose that > > doesn't > > > really work right now. But could we make that work? > > > > In theory yes - but I'm not quite sure how. You'd have more than one > > target that could take control when you said "run" and for Cell I think > > you'd have to disambiguate based on the architecture of the file. But > > Ulrich said they had more patches that weren't ready for mainline and I > > bet some of them make this nicer :-) Since really you would want to > > debug both at once. > > Yes, exactly. It's not just a matter of checking the executable file > architecture; a single process can have threads executing SPU code at > the same as other threads executing PowerPC code. That's not really what I'm talking about. I'm talking about having a single gdb binary that is able to execute both native powerpc code and spu code (but not at the same time). As far as I can tell, it should be possible to do that by implementing to_can_run() in both ppc-linux-nat.c and spu-linux-nat.c, such that only one returns true at any time. > I have a set of patches that does appear to work so far; it is based > primarily on switching current_gdbarch on thread switch. However, > there's still some work to be done before this is in a shape suitable > for mainline inclusion. Andrew Cagney has talked a fair bit about this sort of things in the past. His idea was that each frame would have a gdbarch. But a gdbarch per thread probably makes more sense. > Therefore I'd hoped it would be possible to get the SPU-only port > accepted first, since this is in itself already quite useful. > > I guess what really is throwing us here is the use of "nat". Isn't > > this really more like one of the custom remote-foo.c targets than a > > native target? It just happens to be implemented using PowerPC/Linux > > kernel facilities spelled "ptrace" and some poking around in a PowerPC > > executable in order to implement "run". The ptrace facilities don't > > seem to be used much to talk to the SPU; new files in /proc are used > > instead. It's forking and running a PowerPC executable until it makes > > a special SPU-related syscall, and then it starts talking to the SPU. > > I'll have a look at the remote-foo targets. Is it just more or less just > a matter of renaming the file, or are there significant differences? I don't agree with Daniel here. The spu-linux-nat.c target vector is only usable on a powerpc native debugger. Mark