Re: RFA: Recording MIPS ABI selection in binaries

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

Jeffrey A Law <law@cygnus.com> writes:
>   In message <5tk8dr2tfl.fsf@highland.sibyte.com>you write:
>   > 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.)
>
> ?!!?  These make a huge amount of sense when trying to figure out how
> to interpret code in an object file.

No, something like them makes a huge amount of sense, they themselves
do not.

* it's reasonable to have multiple variants of EF_MIPS_MACH or
EF_MIPS_ARCH in a single object file (though this doesn't happen most
of the time), or if you're a bit loony even in a single function.

* when combining multiple object files, it's absolutely reasonable to
be combining mutiple EF_MIPS_MACH/EF_MIPS_ARCH values.  Consider the
case where you've got generic portable code compiled for, say, mips1,
but then some high-use tuned subroutines selected by function switch.

If automation of ISA detection is desirable (and I think it is), then
you need some mechanism to do it.  However it's plainly obvious that
a file-granularity flag that gets combined when multiple objects are
combined into a single resulting-object-granularity flag is ... not
sufficient.


> Consider the case where two MIPS implementations encode different instructions
> with the same bit pattern.  Yes, this really happens.  The EF_* stuff allows
> the disassembler, gdb & the simulator to figure out how to handle these kinds
> of cases.

In fact, it only allows you to do this if your entire program is
consistently compiled for a given ISA/EF_*, though, right?


> Can this problem be solved by other means, like special sections.  Certainly,
> but a fair number of tools out there depend on those bits now.

That's one of the reasons why i asked some of the questions that I
did, e.g. what other bits really are being used, and how many
"standard" tools depend on them.

It may be possible to design a properly-functioning
backward-compatible set of flags, but that's not going to happen if
people keep throwing things in willy-nilly.


> As to the new architectures -- feel free to send a patch to support them.

I have a substantial response to this, but I really should ask my
higher-ups about it before I make it.  8-)

I didn't want to keep you for this response on that, but i'll send it
as soon as I can.


>Most of the Cygnus/Red Hat folks have had the, err, pleasure of working on
>a large number of MIPS variants -- I counted 20+ MIPS implementations a couple
>years ago that were supported by the GNU tools.

I've had the pleasure of working on a couple, but by no means "many"
or enough to call myself an expert.



chris