Broken SH2a patches

[Nick Clifton]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: sh.patch.3
Type: text/x-troff-man
Size: 83572 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20041220/11d2fd70/attachment.bin>