This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc 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]

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


On Nov 10, 2004, "Maciej W. Rozycki" <macro@mips.com> 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.

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

Other than that, the patch looks good.  Sorry for taking so long to
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.

Note that I don't put or imply any fault on GCC mips maintainers.
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.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}


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