This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [PATCH] (Attempt to) Fix link compatibility check (was: Re:recent mips-elf linker "architecture ... incompatible" regressions)
At Tue, 19 Mar 2002 16:25:16 +0000 (UTC), "Thiemo Seufer" wrote:
> AFAICS your comment also means we shouldn't have any CPU
> header flags.
And I've said as much in the past! 8-)
They're a GNU addition to the not-as-standard-as-you'd-like MIPS ELF
headers.
There are N possible uses for them:
* mark whole binary as being compiled for exactly one specific CPU.
OK, they can do this. This can help with disassembly or simulation,
but there are command line args which allow the right thing to
happen in this case, and at least disassembly could be done with
alternative means (to be invented, AFAIK, though maybe dwarf2 has
something 8-) which mark parts of the binary as using a particular
ISA.
* mark parts of a binary as being compiled for a specific CPU.
They're kinda lame on this front. You can't mix two different
specific-CPU compilations and produce the correct result.cus
Because they are an extension, because they actually don't fit their
purpose particularly well, and because they do get in the way of bits
previously allocated to something else (more ASE bits ... and if you
look at the MIPS documentation, we're on the verge of running out of
the 4 ASE bits that the CPU flag left us with), I think they're going
to cause more problems in the future than they're probably worth.
So, in my opinion, yes, those markings in the flags field should die.
(I added an SB-1 machine ID because, well, as long as it's there to be
used I'm bloody well going to take advantage of it. Scripts where "we
care," e.g. the scripts we use to drive our simulator, always use the
right flags to set the correct architecture. The theory being, people
may well have used some other compilation flags... 8-)
chris