From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17391 invoked by alias); 10 Jan 2005 13:31:58 -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 17300 invoked from network); 10 Jan 2005 13:31:48 -0000 Received: from unknown (HELO lon-del-03.spheriq.net) (195.46.50.99) by sourceware.org with SMTP; 10 Jan 2005 13:31:48 -0000 Received: from lon-inc-07.spheriq.net ([195.46.50.71]) by lon-del-03.spheriq.net with ESMTP id j0ADVlPV030664 for ; Mon, 10 Jan 2005 13:31:47 GMT Received: from lon-out-01.spheriq.net (lon-out-01.spheriq.net [195.46.50.129]) by lon-inc-07.spheriq.net with ESMTP id j0ADVkaN019971 for ; Mon, 10 Jan 2005 13:31:46 GMT Received: from lon-cus-02.spheriq.net (lon-cus-02.spheriq.net [195.46.50.38]) by lon-out-01.spheriq.net with ESMTP id j0ADVi5u016676 for ; Mon, 10 Jan 2005 13:31:46 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 j0ADVhb2026645 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 10 Jan 2005 13:31:44 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 87C5EDA42; Mon, 10 Jan 2005 13:31:42 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id C8CD34722F; Mon, 10 Jan 2005 13:32:21 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 79B3B75969; Mon, 10 Jan 2005 13:32:21 +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 43BC24722F; Mon, 10 Jan 2005 13:32:20 +0000 (GMT) Received: from st.com (chloe.bri.st.com [164.129.15.48]) by mail1.bri.st.com (MOS 3.4.4-GR) with ESMTP id ASC01976 (AUTH "joern rennecke"); Mon, 10 Jan 2005 13:31:39 GMT Message-ID: <41E283BA.90300@st.com> Date: Mon, 10 Jan 2005 13:31:00 -0000 From: Joern RENNECKE User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3) Gecko/20040924 MIME-Version: 1.0 To: Andrew STUBBS Cc: "'Nick Clifton'" , "'Alexandre Oliva'" , binutils@sources.redhat.com Subject: Re: Broken SH2a patches References: <01bb01c4f4b8$4de416d0$0d0f81a4@uk.w2k.superh.com> In-Reply-To: <01bb01c4f4b8$4de416d0$0d0f81a4@uk.w2k.superh.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00089.txt.bz2 Andrew STUBBS wrote: > 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. > While mixing compatible architectures is fine, mixing processors from the sh2e branch with ones from the sh-dsp branch of the family is an absoilute no-no. Unless someone comes up with a mode-switched processor that can run both instruction sets ;-) . On the other hand, mixing code with different ABIs in one executable can make perfect sense, if you have some single-fp heavy code and some double-fp heavy code. You just to make sure that you use proper symbol wrapping for __fpscr_values and use appropriate glue for calling between different ABIs. In fact, we could make gcc do the interlinking automatically with machine specific attributes, if that seems worthwhile. > 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. > Something that will allow a bit more upward compatibility is to list all architectures the code can run on that are not a proper superset of any other listed one. This would be equivalent in terms of described sets and future upward compatibility to the current scheme (the fake nodes stand for intersections of instruction sets of actual processors, just as the architecture lists do). >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). > More exactly, the assembler encodes this information in the object file so that the linker can then do these relaxations. The linker both needs to know about what instructions are available - e.g. braf is only available from SH2 upwards - as well as about what relaxations make sense at all - e.g. the instruction reordering done for SH2 memory access scheduling hurts SH4, and the algorith can also confuse integer and floating point registers.