From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16848 invoked by alias); 31 Jan 2005 11:37:30 -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 16759 invoked from network); 31 Jan 2005 11:37:24 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 31 Jan 2005 11:37:24 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j0VBbNij032549 for ; Mon, 31 Jan 2005 06:37:23 -0500 Received: from talisman.cambridge.redhat.com (talisman.cambridge.redhat.com [172.16.18.81]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j0VBbLO23754; Mon, 31 Jan 2005 06:37:22 -0500 Received: from talisman.cambridge.redhat.com (localhost.localdomain [127.0.0.1]) by talisman.cambridge.redhat.com (8.13.1/8.12.10) with ESMTP id j0VBbGEC026776; Mon, 31 Jan 2005 11:37:16 GMT Received: (from rsandifo@localhost) by talisman.cambridge.redhat.com (8.13.1/8.12.10/Submit) id j0VBbBGe026775; Mon, 31 Jan 2005 11:37:11 GMT X-Authentication-Warning: talisman.cambridge.redhat.com: rsandifo set sender to rsandifo@redhat.com using -f To: Nick Clifton Cc: binutils@sources.redhat.com Subject: Re: Target-specific FDE pointer sizes (2/3) References: <874qh038y1.fsf@redhat.com> <87zmys1szw.fsf@redhat.com> <41FE15A5.8080308@redhat.com> From: Richard Sandiford Date: Mon, 31 Jan 2005 11:37:00 -0000 In-Reply-To: <41FE15A5.8080308@redhat.com> (Nick Clifton's message of "Mon, 31 Jan 2005 11:25:25 +0000") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2005-01/txt/msg00541.txt.bz2 Nick Clifton writes: > Hi Richard, >> As with the bfd patch, we need to distinguish between the official >> LP64 ABI and the not-so-official ILP32 variant. In the case of bfd, >> it was important that we get the size right, and we had to punt if >> we weren't sure. In the case of readelf, I think we just want a >> "best guess", since we have to output _something_. > > I think that if readelf has to guess it should inform the user that it > is doing so. That way the user has a chance to realise that readelf > might have guessed incorrectly and that is why its output does not match > their expectations. Any chance of persuading you otherwise? ;) Three reasons: - It doesn't seem very useful to print a warning if the user has no way of overriding the guess. If we do warn about this, I suppose we'd also have to add a MIPS-EABI64-specific command-line option to readelf, and like I said in my original posting, I'd really rather not do that. There's certainly no precedent with the existing options. - I don't want to warn about unmarked LP64 objects since there's nothing suspect about them. They do exactly what the official ABI said they should do. - People only ended up with unmarked ILP32 objects through using an undocumented combination of gcc command-line options. I think it's reasonable for tools like readelf (and gdb, etc.) to treat EABI objects as being ABI-conforming without any evidence to the contrary. Richard