From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32741 invoked by alias); 29 Oct 2004 13:59:34 -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 32707 invoked from network); 29 Oct 2004 13:59:32 -0000 Received: from unknown (209.128.65.135) by sourceware.org with QMTP; 29 Oct 2004 13:59:32 -0000 Received: (qmail 28194 invoked by uid 10); 29 Oct 2004 13:59:31 -0000 Received: (qmail 31102 invoked by uid 500); 29 Oct 2004 13:59:21 -0000 Mail-Followup-To: nickc@redhat.com, aoliva@redhat.com, binutils@sources.redhat.com, andrew.stubbs@st.com From: Ian Lance Taylor To: Andrew STUBBS Cc: "'Nick Clifton'" , "'Alexandre Oliva'" , Subject: Re: Broken SH2a patches References: <02e501c4bdb0$9f530b50$180f81a4@uk.w2k.superh.com> Date: Fri, 29 Oct 2004 13:59:00 -0000 In-Reply-To: <02e501c4bdb0$9f530b50$180f81a4@uk.w2k.superh.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-10/txt/msg00466.txt.bz2 Andrew STUBBS writes: > Each and every instruction has to be introduced in one single architecture > (albeit imaginary) and then be inherited by each and every one of its > descendents. If this condition is not met then the algorithms in cpu-sh.c > won't work and you find yourself forced to use the --isa option to sort out > the mess. > > With the |s in place as they are the assembler _may_ work ok, but when it > comes to save the file it has to translate that into an elf flag. When there > are actually two architectures chosen (using | in the opcode table) then it > can only choose one and the other information is lost. Therefore, when the > file is loaded, the linker will not believe that it can link it against half > the architectures it actually could link against. This is why you are forced > to tell it which half manually using the -isa option. To make this work, it sounds like you will need to change the ELF header flags, and thus will lose some degree of backward compatibility. If you have to do that anyhow, why not change the ELF flags to more appropriately reflect the situation? Instead of trying to represent all information with a single processor field, partition the instruction set into groups, and use bitfields to indicate which groups are represented in the object file. It would probably be appropriate to continue to have a processor field, to capture certain large groups in a single number. Then add a bit for, e.g., FPU instructions. I don't know how the SH architecture has evolved. Would this sort of approach be possible? Ian