Home Original page

[PATCH] (Attempt to) Fix link compatibility check (was: Re: recent mips-elf linker "architecture ... incompatible" regressions)

cgd@broadcom.com cgd@broadcom.com
Tue Mar 19 09:22:00 GMT 2002 
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
More information about the Binutils mailing list