RE: Broken SH2a patches

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

Hi Nick,

I have been thinking about what you suggested.

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

Presumably we would still need backwards compatibility with the old EF_SH_
numbers. We don't need to generate them, but we do need to read them.

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

So basically you are suggesting we list all the architectures the file can
run on. This is something that I had concidered, but had no idea how to
achieve. 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. I suppose it would work equally well for
any file format that supports non-loadable sections, not just ELF.

This scheme will work within one version of binutils, but what happens when
an upgrade occurs? Old files may cause confusion because they do not list
something they could run on. Of course, this already can happen so maybe it
wouldn't be a problem.

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.

In any case, the four 'fake' architectures have not yet been included in an
official release so, if we want to implement an alternative, we have until
2.16 is released to remove them. Otherwise their EF_SH_ numbers will have to
be supported forever (if perhaps invisibly).

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).

Do you think it worth bothering with any new scheme?

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