From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22120 invoked by alias); 29 Oct 2007 18:04:52 -0000 Received: (qmail 22112 invoked by uid 22791); 29 Oct 2007 18:04:51 -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:04:45 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id CF01A98349; Mon, 29 Oct 2007 18:04:42 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id A56CB98347; Mon, 29 Oct 2007 18:04:42 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.68) (envelope-from ) id 1ImYyf-00028q-Hj; Mon, 29 Oct 2007 14:04:41 -0400 Date: Mon, 29 Oct 2007 18:06:00 -0000 From: Daniel Jacobowitz To: Ulrich Weigand Cc: gdb-patches@sourceware.org Subject: Re: [commit] Use -mabi=altivec for AltiVec tests Message-ID: <20071029180441.GA7736@caradoc.them.org> Mail-Followup-To: Ulrich Weigand , gdb-patches@sourceware.org References: <20071024204239.GO10943@caradoc.them.org> <200710291757.l9THvmfr003711@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200710291757.l9THvmfr003711@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/msg00760.txt.bz2 On Mon, Oct 29, 2007 at 06:57:47PM +0100, Ulrich Weigand wrote: > > 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? I think I will check in my patch, but reduce the number of test cases a bit. I'd like to test only two: -mabi=altivec + "set powerpc vector-abi altivec", and -mabi=altivec + "set powerpc vector-abi auto". The former should always pass. The latter will pass if GCC and LD are new enough. Sound OK? I don't want to test the non-AltiVec-ABI bits because they do not seem to be sensibly defined. I filed PR 33899 last week, which shows the -mabi=no-altivec ABI changing based on -maltivec. We can't and shouldn't detect that. > 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. Right. I thought about this for a couple of days, and we should be able to save and restore them. There's no reason it has to be predicated on -mabi=altivec. Of course, any existing -maltivec -mabi=no-altivec code will still have to be rebuilt. It's terminally broken. -- Daniel Jacobowitz CodeSourcery