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

["Maciej W. Rozycki" <macro at mips dot com>]

On Mon, 22 Nov 2004, Alexandre Oliva wrote:

> >  Then the problem with <sgidefs.h> not being included from some files that 
> > refer to _MIPS_SIM is back, so here's a new version that addresses this 
> > issue as well as a few others that are within the scope.
> 
> I'm surprised you actually needed all these additional includes, while
> I didn't.  Did you add most of them just in case, as opposed to after
> verifying that none of the other headers brought it in as needed?  I
> suppose it doesn't hurt to have excess includes of this header, if it
> makes people feel more confident that the right thing is going to
> happen.

 I made it based on an assumption all files should be self-contained, i.e. 
request all headers they actually need.  It should improve long-term 
maintainability -- regardless of changes in headers that pull others for 
their own use -- implicitly, from a given file's point of view -- the file 
pulls all its own prerequisites.  If one of implicit pulls disappears for 
whatever reason, it won't stop the file from working.

> > -#if (_MIPS_SIM == _MIPS_SIM_ABI32 && _MIPS_SZPTR == 32)
> > +#if _MIPS_SIM == _MIPS_SIM_ABI32
>  
> > -#if (_MIPS_SIM == _MIPS_SIM_ABI32 && _MIPS_SZPTR == 64 /* o64??? */) \
> > -    || _MIPS_SIM == _MIPS_SIM_ABI64
> > +#if _MIPS_SIM == _MIPS_SIM_ABI64
> 
> I'm a bit worried about these changes.  I think they were in place as
> a tentative o64 port that never got completed.  I don't exactly oppose
> the change, but I don't want us to unintentionally remove it.

 An o64 port of MIPS/Linux is not going to happen (an official one, that 
is -- feel free to implemet a private extension).  Actually o64 is such a 
hack it's probably not going to be used for anything new.  It was used for 
some embedded environment IIRC, as a quick and dirty solution due to a 
lack of a better alternative.

> Other than that, the patch looks good.  Sorry for taking so long to

 Not at all.

> review it.  Andreas, I think the patch posted by Maciej on Nov 10
> (this message is In-Reply-To: that posting) is the best for us long
> term.  As I wrote before, using GCC-internal macros is a sure way to
> get burnt when they change.  Since they changed once and broke our use
> thereof, I'd rather steer away from them and stick with well-defined
> ABI macros, that GCC is not going to mess with, ever.

 This was during early days of MIPS/Linux support in the mainline, so 
things could have been a little bit volatile.

> Note that I don't put or imply any fault on GCC mips maintainers.

 Neither do I.

> Although I warned them that the change would break the glibc port, I
> think their decision to make the change was correct, and that relying
> on the GCC-internal macros in glibc was entirely my fault.

 Oh, come on -- this is free software.  Mistakes may happen, but there is 
no such breakage that couldn't be fixed.

 Thanks for your insight.

  Maciej