Re: RFA: Recording MIPS ABI selection in binaries

[cgd at sibyte dot com (Chris G. Demetriou)]

Andrew Cagney <ac131313@cygnus.com> writes:
> "Chris G. Demetriou" wrote:
> > That actually makes me think:
> > 
> > the defined values for EF_MIPS_MACH are unused, and, really, per my
> > previous thought, EF_MIPS_MACH is really better expressed by something
> > like what you're currently proposing.  You could deprecate its use and
> > steal a few bits from it (looks like 4, non-contiguous), without
> > breaking backward compatibility with the defines in the existing
> > headers, if you are careful.
 
(FYI, i think i might have deleted my "previous thought" in an edit of
the message.)

> FYI, EF_MIPS_MACH is used to determine the ISA.  Its fairly orthogonal
> to ABI related flags such as -mgp32.

yes.

And what purpose is there in expressing that a binary uses exactly one
ISA's/CPU's type of instructions, i.e. why should it be encoded the
way it is?  Use of an ISA is not exclusive; you can use multiple ISAs
in a single executable, with (strongly desirable) good effect.

the type of mechanism for recording ABI Nick has proposed is not
particularly appropriate for recording ABI, since it really has no
notion of exclusivity (which as far as I can tell is appropriate for
ABI).  On the other hand, i realized that it's almost perfect for
recording ISA.  8-)

so, steal a few unused bits from that field.  old tools will think the
ISA's unknown, no biggie.  new tools faced with old binaries might get
the ABI wrong... but they'd do that anyway.

and it gets the situation closer to 'right', at least.  (believe me, i
have a strong interest in a sane solution to this problem...)


I just looked through the current set of flags in elf/mips.h.  i guess
i just don't understand why:

* any additional ABI indication needed can't be stuffed into
  one of the existing ABI enumeration slots, e.g. EF_MIPS_ABI,
  which seems to be a value rather than a set of flags, and

* all the bits seem to be gone.  (looking at the current
  header, it looks to me like 0x0f000ed8 are still available.)
  again, i don't know which are reserved by external entites,
  i.e. MTI or SGI.  But it seems that there's still some wiggle-room.



cgd