This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Broken SH2a patches


> That's a tough restriction to impose, though.  In my 
> experience new variants of processors do borrow instructions 
> from one another. Requiring that each instruction be a member 
> of a (possibly pseudo) processor which is an ancestor of each 
> processor which implements that instruction is likely to be 
> quite difficult going forward.  As new processors come out, 
> you will have to reshuffle the graph, introducing new pseudo 
> parent processors.

That's the plan. So far it has been workable. The SH2A shouldn't be a
problem with proper thought. It is conceivable that a change might occur
that is so horrible that we have to think about something else in future,
but the previous changes to the elf flags mean that such a reorganisation
ought to be totally internal and transparent to the user.

> I gather that the goal is to precisely identify which 
> processors may execute a specific executable, based on the 
> set of instructions which appear in that executable.  Is 
> having that precise information especially useful for users 
> in practice?  Would users be OK with knowing "this was 
> compiled for chip X, and will run on any chip which supports 
> this minimal ABI" even if it might run on some other chips also?

The main reason for doing this is that it is the way it has always been
done.

Another reason is that, if the assembler does not infer the architecture
from the contents then how does it know. The only other possibility is that
the user always specify the architecture explicitly, or implicitly by means
of a default. This may be ok when you consider that this is already true for
the compiler. The assembler does have such an option, but traditionally it
has only been used to ensure the correct relaxation optimisations were
performed. Until my patch, this option did not even allow most architecture
variants - only those that had been interesting to somebody or other down
the years.

There is a similar problem with the linker. Given that different
architecture files _can_ be linked together the linker must have some
technique for identifying the output architecture. Of course, if this were
banned there would be no issue.

However there is one major application: The gcc/newlib multilibs are shared
for the various processors that are the same to the compiler (and share the
same ABI) using the MULTILIB_MATCHES mechanism. The libraries are assigned
the most general architecture, but are linkable against all the descendent,
more specific, architectures. (Aside: Ideally I would like the linker to be
able to identify and reject incompatible ABIs, but at present this is not
checked).

When you consider that SH users are used to it as is, I think that there are
more reasons to leave it alone than change it.

I hope this answers your question.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]