From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7376 invoked by alias); 8 May 2003 17:54:56 -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 7285 invoked from network); 8 May 2003 17:54:51 -0000 Received: from unknown (HELO mms2.broadcom.com) (63.70.210.59) by sources.redhat.com with SMTP; 8 May 2003 17:54:51 -0000 Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.5.2)); Thu, 08 May 2003 10:51:35 -0700 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 KAA25832; Thu, 8 May 2003 10:54:24 -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.9/8.12.9/SSF) with ESMTP id h48Hsgov026914; Thu, 8 May 2003 10:54:43 -0700 (PDT) Received: (from cgd@localhost) by dt-sj3-118.sj.broadcom.com ( 8.9.1/SJ8.9.1) id KAA14337; Thu, 8 May 2003 10:54:41 -0700 (PDT) To: aoliva@redhat.com cc: "Eric Christopher" , "Richard Sandiford" , "Thiemo Seufer" , binutils@sources.redhat.com Subject: Re: check mips abi x linker emulation compatibility References: <20030324013532.GA1769@rembrandt.csv.ica.uni-stuttgart.de> <1052325824.19883.0.camel@ghostwheel.sfbay.redhat.com> <1052327219.19883.2.camel@ghostwheel.sfbay.redhat.com> From: cgd@broadcom.com Date: Thu, 08 May 2003 17:54:00 -0000 In-Reply-To: aoliva@redhat.com's message of "Thu, 8 May 2003 16:58:29 +0000 (UTC)" Message-ID: MIME-Version: 1.0 X-WSS-ID: 12A446AD809389-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg00269.txt.bz2 At Thu, 8 May 2003 16:58:29 +0000 (UTC), "Alexandre Oliva" wrote: > How about this instead: add -mabi=neutral or -mabi=from-arch or > something like that, and use this flag on mips targets that have a > non-neutral default? There _isn't_ really a "neutral" ABI, though, is there? Each set of tools is generating to *some* ABI, and the tests are similarly testing *some* ABI. no-abi is just one of the commonly-expected ones (o32 or o64, usually), but not marked, right? It's really there, IMO, for historical purposes, from the days when binaries weren't marked. if it's truly a different ABI... well, that's probably a bug and it should have its ABI named and marked. "-mabi=from-arch" doesn't make any sense whatsoever. Well, OK, i imagine it could be used to select between o32/o64 or 32-bit/64-bit eabi, based on the architecture that's been selected, for tools that default to either 'o'-abi, or 'eabi'... But that's not what you would want to use it for, AFAICT. It sounds like what you're asking for is a "no-abi-marking" flag. I can see how you'd like that, but IMO it's really not the right thing. 8-) cgd