RFA: Recording MIPS ABI selection in binaries

[Chris G. Demetriou]

nickc@redhat.com (Nick Clifton) writes:
>   There is a problem with the MIPS port.

"heh."


>   There is no way for GDB to
>   tell if a binary has been produced with the -mgp32 option.  This
>   means that attempts to debug such binaries will usually fail
>   horribly, since GDB has the wrong idea about the size of various
>   types and so on.

So, i just looked over the flags in the ELF headers.

It's really unfortunate that they've been used in such a haphazard
fashion.  I don't suppose that that's "fixable."  (How many of these
are just used by the gnu tools, vs. other "standard-ish" MIPS tools?
and what would be the pain of fixing the ones which are only used by
GNU tools?)


as far as i'm concerned, there could have been better use of the
existing bits for ABIs (by enumeration, rather than flags) and i just
don't get the point of a bunch of bits, in particular:

EF_MIPS_NOREORDER  (why is it needed?)

EF_MIPS_32BITMODE (what does that actually mean?  "regs are 32-bits
wide" doesn't actually make sense, it may just mean that regs are kept
in 32-bit mode and used only in canonical form, but still there are
ld/sd ops.  if it means even no ld/sd ops, how is it different than
code for a 32-bit processor?

all of the E_MIPS_ARCH_* bits, EF_MIPS_MACH ...  As far as i'm
concerned, these are all redundant or unnecessary.  The type of
machine used to run code, and the type of machine the code is compiled
for -- even down to the ISA -- are orthogonal unless you're doing
kernel exec checking based on these bits (and that'll lose because you
can't be complete).  the E_MIPS_ARCH bits also don't include MIPS_5 or
bits for the new mips32 and mips64 standards.  EF_MIPS_MACH is nice,
and i'm sure satisfied some contract (or something), but it has the
same problem.  These don't affect linking, or really execution either
(it makes sense to link multiple archs' code together, and select at
run time), so other than how to run under a simulator or show in a
disassembler, i don't see how they help.  and those issues can be
solved in another way, and in my opinion should be.  (To compare with
the ABI bits: i can't think how it could make sense to mix different
ABIs in a single executable.)


>   So, I am presenting my patch below for discussion and possible
>   approval.  What do people think ?

I'm by no means a MIPS guru (especially over a long period of time),
but of late i've been forced to attack a few MIPS bits.

Personally I'd like to see the existing flags rationalized to the
extent that they can be, and improved from there, rather than
perpetuate the existing morass and even make it worse by introducing a
mechanism that's not particularly scalable, and is redundant with the
aim of some existing mechanisms.



chris
--
Chris Demetriou, cgd@sibyte.com
Don't even dream that i'm speaking for SiByte.