Re: [patch] MIPS/Linux: Clean up cpp ABI dependencies

[Richard Sandiford <rsandifo at redhat dot com>]

"Maciej W. Rozycki" <macro@mips.com> writes:
> On Mon, 8 Nov 2004, Richard Sandiford wrote:
>> This is no coincidence.  It's very much a requirement that _ABIO32 ==
>> _MIPS_SIM_ABI32, etc.
>
>  Good.  I guess it means I can replace bits like:
>
> #undef _MIPS_SIM_ABI32
> #ifndef _ABIO32
> # define _ABIO32	1
> #endif
> #define _MIPS_SIM_ABI32	_ABIO32
>
> with:
>
> #ifndef _ABIO32
> # define _ABIO32	_MIPS_SIM_ABI32
> #endif
>
> in <sgidefs.h>.

I strongly believe that <sgidefs.h> has no business defining _ABIO32 in
the first place.  It's a GCC invention and a GCC macro.  It certainly
isn't (as the name of the header implies) an SGI definition.

The rule IMO should be:

  (1) If you're going to include <sgidefs.h>, use the macros that
      <sgidefs.h> defines, i.e. _MIPS_SIM_*.

  (2) If you want to use GCC-defined macros (such as for glibc internals)
      and want to retain compatibility with earlier GCC versions that didn't
      define them, handle it in the configure script.  Add -D_ABIO32=1 where
      necessary, etc.

I really don't see why adding _ABIO32 to <sgidefs.h> is going to help.

>> The issue here is that it's up to <sgidefs.h>, not the compiler,
>> to define the _MIPS_SIM_* macros, and you therefore have to include
>> <sgidefs.h> to access them.  But the compiler-defined _MIPS_SIM is
>> designed to be comparable with macros like _MIPS_SIM_ABI32: that's
>> the whole point.
>
>  What's the point in such an awkward setup?

Rhetorical question? ;)  It's not my scheme...

>> GCC also defines _ABIO32 & co. as a convenience for those who don't
>> want to depend on a header file and who don't care about non-gcc
>> (or past-gcc) compatibility.  But...
>
>  How about adding a few words on the matter to GCC info pages e.g. 
> somewhere around the description of the "-mabi=" option?  I could cook 
> some text, but you seem to have a better expertise and access to reference 
> documentation in this area.

I'll put it on the list.

Richard