Re: RFC: should MIPS gas have a -mlong switch?

[Thiemo Seufer <ica2_ts at csv dot ica dot uni-stuttgart dot de>]

Richard Sandiford wrote:
> I'm sure this has been discussed before, but I can't seem
> to find anything in the archives...

http://sources.redhat.com/ml/binutils/2001-10/msg00547.html

> What do folks think about adding -mlong options to MIPS
> gas and storing the long size in the header flags?
> It'd give tighter linker checking, and would allow
> the GDB command line to handle "(long)" correctly.
> 
> If in favour, what's the best way of representing it?
> Some ideas:
> 
> 1. Assume EABI is the only ABI that -mlong can adjust.
>    Add new enums E_MIPS_ABI_EABI32_LONG64 and
>    E_MIPS_ABI_EABI64_LONG32.
> 
>    Pro: no new bits taken, just reusing EF_MIPS_ABI.

It might clash with future "official" EF_MIPS_ABI numbers.

>    Con: doesn't help with "no ABI" (although that might
>         be a good thing from a compatibility standpoint.)
> 
> 2. Add an extra header flag that indicates the
>    "opposite" long size to normal.  Could define
>    either 32-bit or 64-bit longs to be the default
>    for "no ABI".
> 
>    Pro: more general
>    Con: if the flag isn't set, how do you tell between
>         an old file & one that was genuinely assembled
>         with the natural -mlong option?  Might cause
>         backward compatibility problems with "no ABI"
>         code.

Please don't. The no-flag case is already overloaded by meaning "o32"
as well as "no ABI".

> 3. Don't do it.  Get GCC to emit a .gcc_compiled_longXX
>    section instead.
> 
>    Pro: backwards compatible, doesn't need gas to have a -mlong option.

... and stays away from the header flags, which are a very limited
and inflexible resource. These don't scale if the linker wants to
check for other compiler options for some reason.


Thiemo