From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20201 invoked by alias); 29 Oct 2007 17:57:58 -0000 Received: (qmail 20192 invoked by uid 22791); 29 Oct 2007 17:57:57 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate2.de.ibm.com (HELO mtagate2.de.ibm.com) (195.212.29.151) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 29 Oct 2007 17:57:51 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.8/8.13.8) with ESMTP id l9THvm7P153340 for ; Mon, 29 Oct 2007 17:57:48 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 l9THvm9a2322516 for ; Mon, 29 Oct 2007 18:57:48 +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 l9THvm0B003722 for ; Mon, 29 Oct 2007 18:57:48 +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 l9THvmfr003711; Mon, 29 Oct 2007 18:57:48 +0100 Message-Id: <200710291757.l9THvmfr003711@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 29 Oct 2007 18:57:48 +0100 Subject: Re: [commit] Use -mabi=altivec for AltiVec tests To: drow@false.org (Daniel Jacobowitz) Date: Mon, 29 Oct 2007 18:04:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <20071024204239.GO10943@caradoc.them.org> from "Daniel Jacobowitz" at Oct 24, 2007 04:42:39 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/msg00759.txt.bz2 Daniel Jacobowitz wrote: > My understanding (courtesy of Geoff Keating) is that on most PowerPC > targets this only affects the passing of vector registers. On some > (powerpc-eabi; I am not sure if there are others, but I do not know > of any) it increases the required stack alignment. If your CRT files > don't do this, then saving the vector registers may do bad things > to your stack frame. Yes, that was my understanding as well. > For now, what do you think we should do about the option? Restrict it > to Linux? I think we should leave the option in, but for Linux only -- using -mabi=altivec is supposed to work on Linux, and using it has the effect of not only reducing testsuite FAILs, but actually in fact testing the existing GDB code paths. That is, unless we go right ahead and check your ABI detection patch in; this would solve the problem in an even better way ... Would you like me to check in the temporary fix, or would you prefer to simply check in your patch? > http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00438.html > > Perhaps I should ping that now that the .gnu_attribute bit went in > separately. Actually, no, the patch predated my improved > understanding of the stack alignment magic. It might be right > for powerpc-eabi, but powerpc-linux actually does have a sufficiently > aligned stack so it ought to save them properly. OK, I see. That is indeed a serious bug; I wasn't aware of that. It would appear that the ABI defined by -mabi=no-altivec is currently inconsistent with itself, so this absolutely needs to be fixed. However, we should keep in mind the goal of being able to link code built with -mabi=altivec and code built with -mabi=no-altivec, as long as the interfaces between the two do not involve vector types. This implies that -mabi=altivec and -mabi=no-altivec at least agree on which registers are considered call-saved and which are considered call-clobbered. Your patch would break that. I'd suggest to either keep this part of the ABI unchanged between the two, i.e. save/restore vr20..vr31 even in -mabi=no-altivec mode; or else (if saving/restoring proves difficult), treat vr20..vr31 as completely reserved and never use them, as is done by current GCC mainline for AltiVec on AIX. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com