RE: Broken SH2a patches

[Andrew STUBBS <andrew dot stubbs at st dot com>]

> 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?

The way you describe is, more or less what we used to have. The problem was
that the range of architectures outgrew the representation. It became
impossible to insert new architectures with less features than older ones
because there were no numbers in the correct range left.

Simultaneously, the internal representation, in which each architecture had
its own bit in an integer, was extending at an unsustainable rate (given
that each new variant may also come with nofpu, nommu, nofpu-nommu, and dsp
variants).

Therefore, about six months ago now IIRC, we did an overhaul of the way the
architecture detection and recording worked. The values of the pre-existing
elf flags have not changed, but newer architectures no longer follow the
same conventions as the old - i.e. there is no longer any significance to
the value beyond its being a reference into a table.

This change meant that older tools might make incorrect assumptions about
files created for new architectures, but newer tools are totally backward
compatible.

The internal representation, used by the assembler and linker etc., now has
a set of flags denoting what features are available, much as you suggest.
This representation is entirely internal to the code so there can never be
any compatibility issues.

In the course of this work the inheritance tree was properly updated and, as
a result, the sh3-nommu imaginary architecture invented - it was a missing
link in the hierarchy.

This system already did work. It is just the new SH2A architecture patches
which have broken it. The algorithm for determining what the most general
architecture a file will execute on, based on the instruction used within
that file, requires that individual instructions are only introduced to the
inheritance graph in one place, and that once introduced they do not
disappear from the descendents. It is difficult to think of any general
algorithm that can cope with any other arrangement.

The main problem is that, because the system is so new, the only people who
currently have much experience with the stuff is Joern and myself. It might
have been easier if the next architecture to come along had not been such an
evil mix of all the others.

--
Andrew Stubbs
andrew.stubbs@st.com
andrew.stubbs@superh.com