From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31834 invoked by alias); 7 Jan 2005 12:55:37 -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 31767 invoked from network); 7 Jan 2005 12:55:29 -0000 Received: from unknown (HELO lon-del-01.spheriq.net) (195.46.50.97) by sourceware.org with SMTP; 7 Jan 2005 12:55:29 -0000 Received: from lon-inc-10.spheriq.net ([195.46.50.74]) by lon-del-01.spheriq.net with ESMTP id j07CtQjo029347 for ; Fri, 7 Jan 2005 12:55:26 GMT Received: from lon-out-02.spheriq.net (lon-out-02.spheriq.net [195.46.50.130]) by lon-inc-10.spheriq.net with ESMTP id j07CtQEF008346 for ; Fri, 7 Jan 2005 12:55:26 GMT Received: from lon-cus-02.spheriq.net (lon-cus-02.spheriq.net [195.46.50.38]) by lon-out-02.spheriq.net with ESMTP id j07CtPVd009948 for ; Fri, 7 Jan 2005 12:55:26 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by lon-cus-02.spheriq.net with ESMTP id j07CtOan000497 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 7 Jan 2005 12:55:25 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 31EA9DA41; Fri, 7 Jan 2005 12:55:24 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id 285C0473BA; Fri, 7 Jan 2005 12:56:02 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id B19FE7599B; Fri, 7 Jan 2005 12:56:01 +0000 (UTC) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 82FE0473BA; Fri, 7 Jan 2005 12:56:00 +0000 (GMT) Received: from terrorhawk (terrorhawk.bri.st.com [164.129.15.13]) by mail1.bri.st.com (MOS 3.4.4-GR) with ESMTP id ARY04587 (AUTH "andrew stubbs"); Fri, 7 Jan 2005 12:55:20 GMT From: Andrew STUBBS To: "'Nick Clifton'" Cc: "'Alexandre Oliva'" , , "'Joern RENNECKE'" Subject: RE: Broken SH2a patches Date: Fri, 07 Jan 2005 12:55:00 -0000 Organization: STMicroelectronics Message-ID: <01bb01c4f4b8$4de416d0$0d0f81a4@uk.w2k.superh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In-Reply-To: <41C70ABC.8050903@redhat.com> X-O-Virus-Status: No X-O-URL-Status: Not Scanned X-O-CSpam-Status: Not Scanned X-O-Spam-Status: Not scanned X-O-Image-Status: Not Scanned X-O-Att-Status: No X-SpheriQ-Ver: 1.8.3 X-SW-Source: 2005-01/txt/msg00071.txt.bz2 Hi Nick, I have been thinking about what you suggested. > > Whatever technique we use it needs to be able to select an > > architecture, based on the instructions in the file, that > > specifies what architecture the file will run on, without > > excluding any other similar, but different, architectures > > that it may also run on (hence the fake architectures). Any > > ideas? >=20 > The simplest and most extensible scheme would be to drop the=20 > different machine values altogether. Just have one=20 > bfd_mach_sh number=20 > and one EF_SH_ number.=20 Presumably we would still need backwards compatibility with the old EF_SH_ numbers. We don't need to generate them, but we do need to read them. > Instead binary files would have a new .note=20 > section which contains an extensible bit mask of the architectures on=20 > which the instructions in that file can be run. When two or=20 > more files=20 > are combined this mask would be ANDed together to give the=20 > mask for the=20 > output binary and checked via XOR for incompatibilities. So basically you are suggesting we list all the architectures the file can run on. This is something that I had concidered, but had no idea how to achieve. Ideally, if there was an extra section involved, we would also store information about the ABI used in the file, as mixing these is more serious than mixing architectures. I suppose it would work equally well for any file format that supports non-loadable sections, not just ELF. This scheme will work within one version of binutils, but what happens when an upgrade occurs? Old files may cause confusion because they do not list something they could run on. Of course, this already can happen so maybe it wouldn't be a problem. An alternative approach would be to list all the architectures it cannot run on. This would have the effect that old programs would be concidered to run on new architectures, even if they are unsuitable. Perhaps something more intellegent could be done if both sets were known. In any case, the four 'fake' architectures have not yet been included in an official release so, if we want to implement an alternative, we have until 2.16 is released to remove them. Otherwise their EF_SH_ numbers will have to be supported forever (if perhaps invisibly). We would also have to consider the -isa option. Currently it allows individual architectures, which need not change, but also a -up for each, which might no longer make sense. Also, the -isa option is significant because it allows the assembler to use architecture specific relaxation optimisations (which it could not do if it were not certain of the architcture). Do you think it worth bothering with any new scheme? -- Andrew Stubbs andrew.stubbs@st.com andrew.stubbs@superh.com