From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31827 invoked by alias); 29 Oct 2004 14:35:10 -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 31810 invoked from network); 29 Oct 2004 14:35:07 -0000 Received: from unknown (HELO beta.dmz-eu.st.com) (164.129.1.35) by sourceware.org with SMTP; 29 Oct 2004 14:35:07 -0000 Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 4AD88DAC4; Fri, 29 Oct 2004 14:35:05 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id A152F4725E; Fri, 29 Oct 2004 14:35:12 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 50DE5759BE; Fri, 29 Oct 2004 14:35:12 +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 BD62F4725A; Fri, 29 Oct 2004 14:35:10 +0000 (GMT) Received: from terrorhawk (tigger.bri.st.com [164.129.15.24]) by mail1.bri.st.com (MOS 3.4.4-GR) with ESMTP id AML00163 (AUTH "andrew stubbs"); Fri, 29 Oct 2004 15:35:01 +0100 (BST) From: Andrew STUBBS To: "'Ian Lance Taylor'" Cc: "'Nick Clifton'" , "'Alexandre Oliva'" , Subject: RE: Broken SH2a patches Date: Fri, 29 Oct 2004 14:35:00 -0000 Organization: STMicroelectronics Message-ID: <02fd01c4bdc4$bd52b3d0$180f81a4@uk.w2k.superh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In-Reply-To: X-SW-Source: 2004-10/txt/msg00467.txt.bz2 > To make this work, it sounds like you will need to change the=20 > ELF header flags, and thus will lose some degree of backward=20 > compatibility. If you have to do that anyhow, why not change=20 > the ELF flags to more appropriately reflect the situation?=20=20 > Instead of trying to represent all information with a single=20 > processor field, partition the instruction set into groups,=20 > and use bitfields to indicate which groups are represented in=20 > the object file. It would probably be appropriate to=20 > continue to have a processor field, to capture certain large=20 > groups in a single number. Then add a bit for, e.g., FPU=20 > instructions. >=20 > I don't know how the SH architecture has evolved. Would this=20 > sort of approach be possible? The way you describe is, more or less what we used to have. The problem was that the range of architectures outgrew the representation. It became impossible to insert new architectures with less features than older ones because there were no numbers in the correct range left. Simultaneously, the internal representation, in which each architecture had its own bit in an integer, was extending at an unsustainable rate (given that each new variant may also come with nofpu, nommu, nofpu-nommu, and dsp variants). Therefore, about six months ago now IIRC, we did an overhaul of the way the architecture detection and recording worked. The values of the pre-existing elf flags have not changed, but newer architectures no longer follow the same conventions as the old - i.e. there is no longer any significance to the value beyond its being a reference into a table. This change meant that older tools might make incorrect assumptions about files created for new architectures, but newer tools are totally backward compatible. The internal representation, used by the assembler and linker etc., now has a set of flags denoting what features are available, much as you suggest. This representation is entirely internal to the code so there can never be any compatibility issues. In the course of this work the inheritance tree was properly updated and, as a result, the sh3-nommu imaginary architecture invented - it was a missing link in the hierarchy. This system already did work. It is just the new SH2A architecture patches which have broken it. The algorithm for determining what the most general architecture a file will execute on, based on the instruction used within that file, requires that individual instructions are only introduced to the inheritance graph in one place, and that once introduced they do not disappear from the descendents. It is difficult to think of any general algorithm that can cope with any other arrangement. The main problem is that, because the system is so new, the only people who currently have much experience with the stuff is Joern and myself. It might have been easier if the next architecture to come along had not been such an evil mix of all the others. -- Andrew Stubbs andrew.stubbs@st.com andrew.stubbs@superh.com