This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RFC: should MIPS gas have a -mlong switch?


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

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.
   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.

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.
   Con: perpetuates an old hack.

Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]