From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19112 invoked by alias); 15 Nov 2007 00:45:41 -0000 Received: (qmail 19101 invoked by uid 22791); 15 Nov 2007 00:45:41 -0000 X-Spam-Check-By: sourceware.org Received: from relay01.mx.bawue.net (HELO relay01.mx.bawue.net) (193.7.176.67) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 15 Nov 2007 00:45:38 +0000 Received: from lagash (88-106-143-223.dynamic.dsl.as9105.com [88.106.143.223]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by relay01.mx.bawue.net (Postfix) with ESMTP id B191F48BCE; Thu, 15 Nov 2007 00:31:05 +0100 (CET) Received: from ths by lagash with local (Exim 4.68) (envelope-from ) id 1IsSrK-0000SD-LO; Thu, 15 Nov 2007 00:45:30 +0000 Date: Thu, 15 Nov 2007 00:45:00 -0000 From: Thiemo Seufer To: "Joseph S. Myers" Cc: binutils@sourceware.org Subject: Re: [PATCH] MIPS: Add a GNU attribute for -mips32 -mfp64 objects Message-ID: <20071115004530.GU8363@networkno.de> References: <20071114202400.GT8363@networkno.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-11) X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2007-11/txt/msg00170.txt.bz2 Joseph S. Myers wrote: > On Wed, 14 Nov 2007, Thiemo Seufer wrote: > > > While I wrote this patch I noticed that the tagging takes only place > > when the respective gnu_attribute is found in the source code. This > > leaves objects created from assembly untagged. I wonder if it is a good > > idea to generally add a FP ABI attribute, derived from the assembler's > > command line flags, unless this is overridden by a gnu_attribute > > directive in the source. Is there a backward compatibility issue I fail > > to see, or some other effect which makes this a bad idea? > > I didn't think the compiler passed the -msoft-float/-mhard-float ABI > information to the assembler, so this could cause problems with incorrect > tagging when older compilers are used with newer assemblers. The compiler currently doesn't pass down the -m*-float options. So the assembler won't see the option, and therefore won't tag the object. The -mfp64 is passed, but it is AFAICS unlikely to generate invalid tagging: Presumably the reason to use the compiler's -mfp64 option is to generate 64-bit FP code, which isn't compatible to the other variants as soon as e.g. a mfhc1 instruction is used. The idea is to pass the relevent options to the assembler (at least for .s/.S source files, for compiler generated files it would be redundant). > The ABI is a > separate matter from what instructions are enabled, and a valid ABI is > being compatible with both hard and soft float; a file with purely integer > instructions could be a soft-float file if the functions are taking > floating-point parameters, or a file compatible with both if they are > taking integer parameters. How would you deduce the C language function > call compatibility of an object (which is what the attributes describe) > from the assembler source and command line options? I think of all those, soft-float and "no-float" are the only compatible ones. They would stay link compatible, as "no FP option" means tag 0. A hard-float object which happens not to use floating point at all wouldn't be link compatible any more, this is the same effect which was evidently regarded as acceptable in newer GCC compilers. Thiemo