From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2192 invoked by alias); 29 Oct 2004 15:44:55 -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 2185 invoked from network); 29 Oct 2004 15:44:53 -0000 Received: from unknown (HELO beta.dmz-eu.st.com) (164.129.1.35) by sourceware.org with SMTP; 29 Oct 2004 15:44:53 -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 D54BCDCA9; Fri, 29 Oct 2004 15:44:43 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id 338D84728E; Fri, 29 Oct 2004 15:44:51 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id E664875969; Fri, 29 Oct 2004 15:44:50 +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 AD4E847286; Fri, 29 Oct 2004 15:44:49 +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 AML00864 (AUTH "andrew stubbs"); Fri, 29 Oct 2004 16:44:40 +0100 (BST) From: Andrew STUBBS To: "'Ian Lance Taylor'" Cc: "'Nick Clifton'" , "'Alexandre Oliva'" , Subject: RE: Broken SH2a patches Date: Fri, 29 Oct 2004 15:44:00 -0000 Organization: STMicroelectronics Message-ID: <030401c4bdce$782a3080$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/msg00471.txt.bz2 > That's a tough restriction to impose, though. In my=20 > experience new variants of processors do borrow instructions=20 > from one another. Requiring that each instruction be a member=20 > of a (possibly pseudo) processor which is an ancestor of each=20 > processor which implements that instruction is likely to be=20 > quite difficult going forward. As new processors come out,=20 > you will have to reshuffle the graph, introducing new pseudo=20 > parent processors. That's the plan. So far it has been workable. The SH2A shouldn't be a problem with proper thought. It is conceivable that a change might occur that is so horrible that we have to think about something else in future, but the previous changes to the elf flags mean that such a reorganisation ought to be totally internal and transparent to the user. > I gather that the goal is to precisely identify which=20 > processors may execute a specific executable, based on the=20 > set of instructions which appear in that executable. Is=20 > having that precise information especially useful for users=20 > in practice? Would users be OK with knowing "this was=20 > compiled for chip X, and will run on any chip which supports=20 > this minimal ABI" even if it might run on some other chips also? The main reason for doing this is that it is the way it has always been done. Another reason is that, if the assembler does not infer the architecture from the contents then how does it know. The only other possibility is that the user always specify the architecture explicitly, or implicitly by means of a default. This may be ok when you consider that this is already true for the compiler. The assembler does have such an option, but traditionally it has only been used to ensure the correct relaxation optimisations were performed. Until my patch, this option did not even allow most architecture variants - only those that had been interesting to somebody or other down the years. There is a similar problem with the linker. Given that different architecture files _can_ be linked together the linker must have some technique for identifying the output architecture. Of course, if this were banned there would be no issue. However there is one major application: The gcc/newlib multilibs are shared for the various processors that are the same to the compiler (and share the same ABI) using the MULTILIB_MATCHES mechanism. The libraries are assigned the most general architecture, but are linkable against all the descendent, more specific, architectures. (Aside: Ideally I would like the linker to be able to identify and reject incompatible ABIs, but at present this is not checked). When you consider that SH users are used to it as is, I think that there are more reasons to leave it alone than change it. I hope this answers your question. -- Andrew Stubbs andrew.stubbs@st.com andrew.stubbs@superh.com