From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24215 invoked by alias); 31 Jan 2005 12:15:27 -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 23736 invoked from network); 31 Jan 2005 12:15:02 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 31 Jan 2005 12:15:02 -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 j0VCF2lj008447 for ; Mon, 31 Jan 2005 07:15:02 -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 j0VCF0O31441; Mon, 31 Jan 2005 07:15:00 -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 j0VCEsdX027351; Mon, 31 Jan 2005 12:14:54 GMT Received: (from rsandifo@localhost) by talisman.cambridge.redhat.com (8.13.1/8.12.10/Submit) id j0VCEnG0027350; Mon, 31 Jan 2005 12:14:49 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> <41FE1D13.3040104@redhat.com> From: Richard Sandiford Date: Mon, 31 Jan 2005 12:15:00 -0000 In-Reply-To: <41FE1D13.3040104@redhat.com> (Nick Clifton's message of "Mon, 31 Jan 2005 11:57:07 +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/msg00544.txt.bz2 Nick Clifton writes: >> - 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. > > Well no. One of readelf's main purposes is to be used as a tool to > investigate broken binaries. Therefore it should never assume that any > file is compliant with an ABI, just because it is supposed to be. It > should always be paranoid and check for compliance, and alert the user > to any discrepancies. But in the case of LP64 objects, there are no discrepancies. That's my point. As far as the ABI spec is concerned, these objects have exactly the form they're supposed to have. They were never supposed to be marked with a .gcc_compiled_long64 section. In other words, if we do have the warning, we'll be warning about objects that do exactly what the ABI says they should do. Objects that IMO we have little reason to believe might be invalid. The ILP32 variation is one of those things that "just happened". I talked about it being "semi-official", but I should really have said that it's only semi-official in versions of gcc that emit .gcc_compiled_long32 sections. As far as I'm concerned, it's just not supported in earlier toolchains. I only handled it in the bfd patch because (in that context) it was easy to do without any detrimental affect to objects that follow the real ABI. > Furthermore it should not seg fault or break when it is given a broken > binary to investigate and it should gracefully handle any corruption > that it encounters. FWIW, I've not seen the wrong address size cause readelf to segfault. Anyway, I don't want this thread to degenerate into a long and pointless flamewar. My objections are on record, and I've made then as best I can. If you still insist on the warning after the above, just say so, and I'll add it without any more whinging. Richard