From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32689 invoked by alias); 23 Feb 2005 14:26:42 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 32295 invoked from network); 23 Feb 2005 14:26:30 -0000 Received: from unknown (HELO iris1.csv.ica.uni-stuttgart.de) (129.69.118.2) by sourceware.org with SMTP; 23 Feb 2005 14:26:30 -0000 Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de with esmtp id 1D3xSY-0006Sk-00; Wed, 23 Feb 2005 15:25:50 +0100 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 1D3xSX-00080v-00; Wed, 23 Feb 2005 15:25:49 +0100 Date: Wed, 23 Feb 2005 16:39:00 -0000 To: Richard Sandiford Cc: Eric Christopher , "Maciej W. Rozycki" , binutils@sources.redhat.com, "Maciej W. Rozycki" Subject: Re: [PATCH] MIPS gas/ld test suite portability fixes Message-ID: <20050223142549.GA30173@rembrandt.csv.ica.uni-stuttgart.de> References: <20050222211319.GC7729@rembrandt.csv.ica.uni-stuttgart.de> <20050222220154.GE7729@rembrandt.csv.ica.uni-stuttgart.de> <1109110466.5032.25.camel@localhost.localdomain> <20050222225421.GF7729@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i From: Thiemo Seufer X-SW-Source: 2005-02/txt/msg00557.txt.bz2 Richard Sandiford wrote: [snip] > Eric's already mentioned the old gcc behaviour of -mabi=64 implying > -mips4, but remember that -mabi=32 also used to imply -mips1, on the > basis that that's what the SVR4 ABI officially requires. IIRC it was first the other way: -mabi didn't exist, -mips1/2 implied o32, -mips3 implied n32, and -mips4 implied n64. This emulated the IRIX toolchain's behaviour, and was found to be inadequate for other mips platforms. Then -mabi was added, and reverse-implied -mipsX, this opened the door for several inconsistencies. I don't want to follow that path, I only want -mabi to ensure it has the minimum ABI requirement satisfied. [snip] > Your proposal seems to be catering for the case where: > > (a) someone picks a 32-bit-only configuration that implies > a particular architecture; and > > (b) then tries to use it to build 64-bit code. This currently works for mips-linux-gcc -mabi=n32 thanks to from-abi but fails for mipsisa32-linux-gcc -mabi=n32 This inconsistency is introduced just because the toolchain's ISA default is different to MIPS I. > Outside of running testsuites, who actually does that? It's a minor > market, surely? With the market argument you can "prove" that there's no need for more than one processor architecture. :-) But I agree, it is not a widely used feature. > Anyone who's seriously interested in building 64-bit > code should use a 64-bit configuration, not something like mipstx39-elf, > mipsisa32-linux-gnu or whatever. That's especially true when you > consider that a 32-bit-only configuration won't build any compatible > libraries. Which is IMHO a bug in gcc, because -mabi=n?? should be fully usable. (If this isn't true for some mips*-elf targets, then -mabi should probably be an invalid option for these.) Thiemo