From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23020 invoked by alias); 8 May 2003 18:30:23 -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 22936 invoked from network); 8 May 2003 18:30:22 -0000 Received: from unknown (HELO mms1.broadcom.com) (63.70.210.58) by sources.redhat.com with SMTP; 8 May 2003 18:30:22 -0000 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.5.2)); Thu, 08 May 2003 11:30:05 -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 LAA04170; Thu, 8 May 2003 11:29:53 -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 h48IUBov027803; Thu, 8 May 2003 11:30:11 -0700 (PDT) Received: (from cgd@localhost) by dt-sj3-118.sj.broadcom.com ( 8.9.1/SJ8.9.1) id LAA14930; Thu, 8 May 2003 11:30:10 -0700 (PDT) To: "Alexandre Oliva" 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 18:30:00 -0000 In-Reply-To: "Alexandre Oliva"'s message of "08 May 2003 15:19:39 -0300" Message-ID: MIME-Version: 1.0 X-WSS-ID: 12A47DA73942115-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg00271.txt.bz2 At 08 May 2003 15:19:39 -0300, Alexandre Oliva wrote: > > There _isn't_ really a "neutral" ABI, though, is there? > > What if none of the ABI bits are set? The binary's ABI still isn't neutral; it's one of, and compatible with only one of, the other ABIs. we just don't know which one, so we should allow it to be *linked* with any other. IMO, though, it's not particularly desirable for the assembler to *ever* create (elf32) binaries w/o ABI markings, these days. (it may be reasonable to have a 'no (known) abi' used explicitly for things like blobs turned into .o files by objdump or maybe even ld.) > Except for the fact that we have to make a choice between elf32 or > elf64 early on, it can remain neutral for longer... well, the bits used in elf32 for ABI flags are currently not used at all in elf64, and elf64 binaries are currently *always* n64, right? > > It sounds like what you're asking for is a "no-abi-marking" flag. > > Nope. I want something that disables the assembler's default, so that > it can figure it out as if the target configured for was a generic > mips target. even 'generic' MIPS targets assemblers might use some ABIs. they might (erroneously, IMO) not mark them on the binaries, though. 8-) chris