From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2433 invoked by alias); 6 Oct 2007 16:05:05 -0000 Received: (qmail 2405 invoked by uid 22791); 6 Oct 2007 16:05:04 -0000 X-Spam-Check-By: sourceware.org Received: from igw1.br.ibm.com (HELO igw1.br.ibm.com) (32.104.18.24) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 06 Oct 2007 16:05:02 +0000 Received: from mailhub1.br.ibm.com (mailhub1 [9.18.232.109]) by igw1.br.ibm.com (Postfix) with ESMTP id 6930432C0BC for ; Sat, 6 Oct 2007 12:46:21 -0300 (BRT) Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by mailhub1.br.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l96G4xSI3227702 for ; Sat, 6 Oct 2007 13:04:59 -0300 Received: from d24av01.br.ibm.com (loopback [127.0.0.1]) by d24av01.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l96G4w0f026771 for ; Sat, 6 Oct 2007 13:04:59 -0300 Received: from hactar.local ([9.8.4.86]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l96G4wlS026767; Sat, 6 Oct 2007 13:04:58 -0300 Subject: Re: [rfc] Use target descriptions for PowerPC From: Thiago Jung Bauermann To: Daniel Jacobowitz Cc: gdb-patches@sourceware.org In-Reply-To: <20071005235904.GA24514@caradoc.them.org> References: <20071005163754.GA26041@caradoc.them.org> <1191620446.18959.18.camel@localhost.localdomain> <20071005235904.GA24514@caradoc.them.org> Content-Type: text/plain Date: Sat, 06 Oct 2007 16:05:00 -0000 Message-Id: <1191686695.18959.53.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-10/txt/msg00090.txt.bz2 On Fri, 2007-10-05 at 19:59 -0400, Daniel Jacobowitz wrote: > On Fri, Oct 05, 2007 at 06:40:46PM -0300, Thiago Jung Bauermann wrote: > > Hi Daniel, > > > > On Fri, 2007-10-05 at 12:37 -0400, Daniel Jacobowitz wrote: > > > + /* If we have a 64-bit binary on a 32-bit target, complain. Also > > > + complain for a 32-bit binary on a 64-bit target; we do not yet > > > + support that. */ > > > + if (tdesc_wordsize != -1 && tdesc_wordsize != wordsize) > > > + { > > > + tdesc_data_cleanup (tdesc_data); > > > + return NULL; > > > + } > > > > Sorry if I am confusing things here. This sounds like it affects 64 bit > > GDB debugging 32 bit binary. Is this the case? Or only for remote > > debugging? > > Good noticing, it could be a problem, but it works out fine - we don't > have a supplied target description in this case, so we pick a default > based on the 32-bit binary, and get a 32-bit binary; everything > matches. Then the GNU/Linux native code handles the details. I've > just tested that. > > The problem I'm trying to prevent is that we will always use registers > of the size described by the target description. And we don't support > implementing the 32-bit ABI on top of 64-bit GPRs; we'll copy > arguments into the high half of registers when calling functions, for > instance. Try connecting a GDB to a 64-bit gdbserver and it will go > wrong in a couple of ways. The native targets fake this by knowing > how to supply 32-bit registers when expected, even if you'd think > there ought to be 64-bit registers. Nice, thanks for the explanation. Would you mind expanding the comment in the code above to include it? -- []'s Thiago Jung Bauermann Software Engineer IBM Linux Technology Center