This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: [patch] MIPS/Linux: Clean up cpp ABI dependencies
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>.
> 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?
> To quote from SGI's implementation of <sgidefs.h>:
>
> * If you use the _MIPS_* defines, you should include this header file.
> * In order to avoid problems when sgidefs.h is not included, the driver
> * predefines _MIPS_ISA and _MIPS_SIM to be the actual values (1-4)
> * rather than the _MIPS_* names (otherwise, if sgidefs.h is not
> * included, we would be defining _MIPS_SIM to be an undefined value).
>
> Not an ideal arrangement perhaps, since comparisons against an undefined
> _MIPS_SIM_* macro won't generate an error. But that's how the interface
> is defined (by SGI, I mean, not gcc maintainers ;).
Well, it's for their systems -- IRIX, I presume. Linux is not IRIX, so
it does not have to follow something else's braindamage.
> 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.
> The _MIPS_SIM_* macros are definitely more backwards-compatible though.
> FWIW, I think gcc should continue using them.
Well, I don't ask for removing the _MIPS_SIM_* macros, so compatibility
for user code should won't be affected. For glibc itself backward
compatibility seems not be much of an issue -- it already requires GCC >=
3.2 and bumpig that requirement is likely just a matter of time.
Maciej