From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2912 invoked by alias); 29 Oct 2007 18:11:34 -0000 Received: (qmail 2842 invoked by uid 22791); 29 Oct 2007 18:11:33 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate4.de.ibm.com (HELO mtagate4.de.ibm.com) (195.212.29.153) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 29 Oct 2007 18:11:30 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.8/8.13.8) with ESMTP id l9TIBR6B157360 for ; Mon, 29 Oct 2007 18:11:27 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l9TIBR8H1876170 for ; Mon, 29 Oct 2007 19:11:27 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l9TIBRkR017632 for ; Mon, 29 Oct 2007 19:11:27 +0100 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id l9TIBRpc017629; Mon, 29 Oct 2007 19:11:27 +0100 Message-Id: <200710291811.l9TIBRpc017629@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 29 Oct 2007 19:11:27 +0100 Subject: Re: [rfc] PowerPC ABI detection and overrides To: drow@false.org (Daniel Jacobowitz) Date: Mon, 29 Oct 2007 18:27:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <20071025195932.GA4791@caradoc.them.org> from "Daniel Jacobowitz" at Oct 25, 2007 03:59:32 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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/msg00762.txt.bz2 Daniel Jacobowitz wrote: > Run the test four times: > > - With -mabi=no-altivec and "set powerpc vector-abi generic". > - With -mabi=altivec and "set powerpc vector-abi altivec". > - With no ABI option and "set powerpc vector-abi auto". > - With -mabi=altivec and "set powerpc vector-abi auto". > > I think this covers all the sensible combinations. This looks excellent! > 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? > Unfortunately the -mabi=no-altivec tests fail. I filed GCC PR > 33899 about this. In the current scenario there is no way we > can get this right. I'm not going to commit this until I've at least > discussed that with David. Hmmm, yet another problem I wasn't aware of ... 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. The third vector return ABI only comes into play if you explicitly use the GCC-internal vector type via attribute ((vector_size (16))), and do not use -maltivec. In this situation, GCC will currently indeed return vector values by reference, but the code will trigger a compiler warning: xxx.c:5: warning: GCC vector returned by reference: non-standard ABI extension with no compatibility guarantee I do not think that under these circumstances there can be any reasonable expectation for GDB to handle that situation. 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). > @@ -3027,6 +3049,9 @@ rs6000_gdbarch_init (struct gdbarch_info > +#ifdef HAVE_ELF > + if (soft_float_flag == AUTO_BOOLEAN_AUTO && from_elf_exec) > + { > + switch (bfd_elf_get_obj_attr_int (info.abfd, OBJ_ATTR_GNU, > + Tag_GNU_Power_ABI_FP)) 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 ... (This doesn't mean I don't want this patch to go in -- I'm aware that we're current looking at the BFD anyway. I'm just wondering if you have any ideas how this could be improved ...) Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com