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


Andrew STUBBS <andrew.stubbs@st.com> writes:

> The way you describe is, more or less what we used to have.

I see.  Thanks.

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

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.

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?

Ian


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