From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20994 invoked by alias); 29 Oct 2007 18:32:36 -0000 Received: (qmail 20982 invoked by uid 22791); 29 Oct 2007 18:32:34 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 29 Oct 2007 18:32:32 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id AC6AF98349; Mon, 29 Oct 2007 18:32:30 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 905E798347; Mon, 29 Oct 2007 18:32:30 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.68) (envelope-from ) id 1ImZPZ-00030H-Om; Mon, 29 Oct 2007 14:32:29 -0400 Date: Mon, 29 Oct 2007 18:38:00 -0000 From: Daniel Jacobowitz To: Ulrich Weigand Cc: gdb-patches@sourceware.org Subject: Re: [rfc] PowerPC ABI detection and overrides Message-ID: <20071029183229.GA10700@caradoc.them.org> Mail-Followup-To: Ulrich Weigand , gdb-patches@sourceware.org References: <20071025195932.GA4791@caradoc.them.org> <200710291811.l9TIBRpc017629@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200710291811.l9TIBRpc017629@d12av02.megacenter.de.ibm.com> User-Agent: Mutt/1.5.15 (2007-04-09) 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/msg00764.txt.bz2 On Mon, Oct 29, 2007 at 07:11:27PM +0100, Ulrich Weigand wrote: > > You will need > > a relatively current GCC and very current linker for the auto tests > > to all pass. > > Any chance of making those tests XFAIL instead of FAIL if the > toolchain is too old? Most will pass anyway. The default ABI selection is going to be AltiVec because the default set of registers include AltiVec registers. I'll try to find some tools I can use to confirm that before I check it in though. I can probably come up with an XFAIL approach. I'll need some other way to check that the attributes are present. Maybe objdump. > However, this may not be quite as bad as it seems: note that while > in your bugzilla report, you're refering to use of "__vector int", > this actually doesn't work: the "AltiVec vector" types introduced > via the __vector or vector keywords are only available in the first > place if you use -maltivec; otherwise that code is rejected with a > syntax error anyway. Thanks, I'd forgotten about that. > So I would suggest that GDB interprets the "generic" case always > as the "-maltivec -mabi=no-altivec" situation, and expects 16-byte > vector return values in general-purpose registers. This would also > fix our test cases (as those use the Altivec vector syntax and thus > reqiure -maltivec anyway). Interesting. Very interesting. I'll double-check that this works and switch to it if it does. Then maybe I can test more of the cases. > Hmmm, I would have hoped we could get away from directly refering > to the BFD in the gdbarch_init routine ... It would be nicer to > more strictly distinguish between detecting ABI properties from > the BFD (in the *sniffer*), and installing an gdbarch handler > supporting a particular set of ABI properties (in the gdbarch_init > routine). > > This would allow to request a specific gdbarch in the situation > where you know exactly which ABI properties you need, but don't > have any BFD handy ... Can you give me an example of when you want to do that? In general I've been moving away from it - there's too much extra bookkeeping that the BFD does for us. -- Daniel Jacobowitz CodeSourcery