From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5119 invoked by alias); 13 Jul 2002 07:52:39 -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 4284 invoked from network); 13 Jul 2002 07:51:22 -0000 Received: from unknown (HELO mms2.broadcom.com) (63.70.210.59) by sources.redhat.com with SMTP; 13 Jul 2002 07:51:22 -0000 Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom MMS-2 SMTP Relay (MMS v4.7)); Sat, 13 Jul 2002 00:49:25 -0700 X-Server-Uuid: 2a12fa22-b688-11d4-a6a1-00508bfc9626 Received: from mail-sj1-5.sj.broadcom.com (mail-sj1-5.sj.broadcom.com [10.16.128.236]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id AAA26815; Sat, 13 Jul 2002 00:51:20 -0700 (PDT) Received: from dt-sj3-118.sj.broadcom.com (dt-sj3-118 [10.21.64.118]) by mail-sj1-5.sj.broadcom.com (8.12.4/8.12.4/SSF) with ESMTP id g6D7pKER009274; Sat, 13 Jul 2002 00:51:20 -0700 (PDT) Received: (from cgd@localhost) by dt-sj3-118.sj.broadcom.com ( 8.9.1/SJ8.9.1) id AAA14661; Sat, 13 Jul 2002 00:51:19 -0700 (PDT) To: echristo@redhat.com cc: "Maciej W. Rozycki" , "Richard Sandiford" , gcc-patches@gcc.gnu.org, binutils@sources.redhat.com Subject: Re: RFC & patch: Rework MIPS command-line handling References: <1026512048.25426.47.camel@ghostwheel.cygnus.com> From: cgd@broadcom.com Date: Sat, 13 Jul 2002 19:56:00 -0000 In-Reply-To: echristo@redhat.com's message of "Fri, 12 Jul 2002 22:16:06 +0000 (UTC)" Message-ID: MIME-Version: 1.0 X-WSS-ID: 1131040F68958-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-SW-Source: 2002-07/txt/msg00280.txt.bz2 At Fri, 12 Jul 2002 22:16:06 +0000 (UTC), "Eric Christopher" wrote: > > How can you guess an ABI from anything else? If I pass the "-march=4000" > > option, then which ABI do I mean? If I pass "-mips4" for conditional > > moves, then why should I add "-32" to keep the ABI unchanged? OK, if done > > carefully, the guess may probably be made harmless to uninterested parties > > -- I'll have to study the proposed changes thorougly to decide if the new > > code does it in an acceptable way. > > 1) -march=4000 > This will be a) ABI by default if it was configured with a compatible > abi. The "next compatible" abi if not. An idea was to warn if we had to > change the ABI. I don't know what people think about this - I do know > that many people get testy if new warnings are produced. > > 2) -mips4 -32 > This won't work anyhow. This will produce an error. > > I'll accept any feedback. Other than conceivably making gas > non-intuitive (which is something i've also heard from Daniel), I can't > see any other way for a reasonable set of command line options. So, i don't know how much of a problem it would be, but at least erroring with various ABI specs might play havoc with multilibs. (in particular, you'd then need all sorts of excludes...) actually, given that there are now multiple ways to specify everything (arch, cpu, etc.), it would seem that you need to have code, rather than option string matching, determine which multilib you're currently building or should be using, eh? i.e.: say mips-elf builds multilibs for -mips1/-mips3... you want -march=r4000 if specified on the command line to get -mips3. actually, you also want -march=r5000 to get -mips3, if -mips1 and -mips3 are your only choices... You can do some of this with MULTILIB_MATCHES, but you can't do "fall back" at all can you. So i guess MULTILIB_MATCHES has to learn all of the arch and ISA names? oi. and if somebody wants to make that better, or wants to allow "fall back" to best available lib, they have to hack the insides of the multilib selection code so that it uses something other than specs... (BTW, i think the compiler shouldn't _have_ to pass the assembler the correct default ABI flag, i.e. so that code built with 'as' w/o flags works right by default... but I think it should be passing the default or non-default ABI-related flags at all times "just to be safe" from a badly-built as. But that goes into the rabbit hole of killing specs for invocation of as, doesn't it...) OK, tally a few more points for "specs must die." 8-) chris