Re: PATCH: Fix the MIPS ISA ELF setting (Re: RedHat 7.1/mipsupdate)

[cgd at broadcom dot com]

"H . J . Lu" <hjl@lucon.org> writes:
> I believe it is the wrong approach. If you do this, you may not get the
> architecture bit in the ELF header, which is very much misleading. I
> do want that bit if the binary contains instructions specific to that
> architecture..

Strongly disagree.

If you compile with e.g. -march=foo, yes, you "definitely"(*) want the
bits set in the ELF header.  However, if you don't, and just use a few
instructions in inline assembly, then I don't think you want the bits
in the ELF header at all.

The ELF header could be "reasonably"(*) used to determine whether or
not to run the binary on a given processor, etc.  However, the special
instructions in inline assembly may well be hidden in functions or in
code sequences which are only used on certain processors, e.g. as an
optimization if you know you're on a given machine.

So, you really don't want to mark the binary overall that it's for
that machine.


(*) Actually, I don't think you _ever_ should mark the ELF header with
the CPU type of information, unless the purpose is specifically and
solely to indicate that the OS shouldn't run it on other machine
types.  (Doing so is an extension in the FSF tools AFAICT, and IMO an
ill-though-out one.)

Why?  Well, at the very least, there's the disassembly problem.

Setting the CPU type in the ELF header is a nice hint at how to
disassemble files, but it's often misleading.  In general, if you're
using ".set mipsN" you're going to be in a situation where the
assembler won't want to disassemble your instructions.  (Even if you
change the assembler to disassemble "everything," which I don't think
is Right, you still have to figure out what to do with _conflicting_
instructions.) 

So, what if you do two _different_ ".set mipsN" commands in a single
file?  Or, to take the example further, what if you make two different
objects with -march=foo and -march=bar (e.g. to provide special
optimized function variants for those machines), then ... link them
together?

Setting the bits in the ELF header is ... utterly incapable of coping
with this, and so (IMO) shouldn't be depended on for diassembly.

What you really "want" is some method of marking PC ranges in object
files as being asm for a particular ISA or CPU (then a method of
merging them on link, etc.).  I don't suspect that that would be
horribly difficult, but I wouldn't even know where to begin
implementing it...


cgd