RE: Broken SH2a patches

[Andrew STUBBS <andrew.stubbs@st.com>]

The patch is good but I spotted a mistake in the test results:

+ sh.s                 -isa=sh2a-nofpu-or-sh3-nommu
sh2a-nofpu-or-sh4-nommu-nofpu

There are similar mistakes for most of the results for this -isa option.

I have traced this to here:

! #define arch_sh2a_nofpu_or_sh4_nommu_nofpu
(arch_sh2a_sh3_base|arch_sh_no_mmu |arch_sh_no_co)
! #define arch_sh2a_nofpu_or_sh3_nommu
(arch_sh2a_sh3_base|arch_sh_no_mmu |arch_sh_no_co)

Note that both architectures have the same flags.

I'm in the process or testing it further.

-- 
------------------------------------------------------------------------
|  Andrew Stubbs,                 |  E-mail: Andrew.Stubbs@st.com      |
|  STMicroelectronics (R&D) Ltd., |  or      Andrew.Stubbs@superh.com  |
|  1000 Aztec West,               |                                    |
|  Almondsbury,                   |  Tel:    +44 (0)1454 462611        |
|  Bristol, BS32 4SQ, U.K.        |  Fax:    +44 (0)1454 462305        |
------------------------------------------------------------------------


> -----Original Message-----
> From: Nick Clifton [mailto:nickc@redhat.com] 
> Sent: 20 December 2004 17:24
> To: Andrew STUBBS
> Cc: 'Alexandre Oliva'; binutils@sources.redhat.com; 'Joern RENNECKE'
> Subject: Re: Broken SH2a patches
> 
> 
> Hi Andrew,
> 
>  > 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?
> 
>    The simplest and most extensible scheme would be to drop the 
> different machine values altogether.  Just have one 
> bfd_mach_sh number 
> and one EF_SH_ number.  Instead binary files would have a new .note 
> section which contains an extensible bit mask of the architectures on 
> which the instructions in that file can be run.  When two or 
> more files 
> are combined this mask would be ANDed together to give the 
> mask for the 
> output binary and checked via XOR for incompatibilities.
> 
>    Each instruction would also need one of these bitmasks.  
> When a new 
> architecture is added every instruction's bitmask would have to be 
> updated if it was supported by the new architecture.  This would only 
> have to be done once though and there are macros that could 
> be defined 
> to make it simpler.
> 
> Anyway attached is a revised patch that includes your diagram of the 
> dependencies (thanks) as well as some new base values and a 
> fixed set of 
> architecture definitions.  (The problem you noticed with the 
> -isa=sh2e 
> selecting the sh2a-or-sh3e architecture was that the original 
> definition 
> of arch_sh2e defined it in terms of both sh2e_base and sh2a_base).
> 
> I have also tweaked the #defines for the various base architecture 
> values so it should be easier to add new ones in the future.
> 
> What do you think of this version ?
> 
> Cheers
>    Nick
> 
> 
>