svn commit: r217147 - in head/sys: amd64/include arm/include i386/include ia64/include mips/include powerpc/include sparc64/include sun4v/include

[Juli Mallett]

On Sat, Jan 8, 2011 at 04:43, Tijl Coosemans <tijl at freebsd.org> wrote:
> Author: tijl
> Date: Sat Jan  8 12:43:05 2011
> New Revision: 217147
> URL: http://svn.freebsd.org/changeset/base/217147
>
> Log:
>  On mixed 32/64 bit architectures (mips, powerpc) use __LP64__ rather than
>  architecture macros (__mips_n64, __powerpc64__) when 64 bit types (and
>  corresponding macros) are different from 32 bit. [1]

I don't know why you didn't talk with MIPS people at all about these
changes.  That they were reviewed by Bruce is very reassuring in
aesthetic terms, but that's hardly sufficient.

This and other changes have made it harder to support common MIPS
configurations and compilation options on FreeBSD.  I'm glad you're at
least aware of n32 (as indicated in another message) and its
implications, but the use of ABI-specific names was deliberate.  Have
you thought about -n32 with -mlong64?  It isn't the same kind of dirty
hack as Bruce talks about when he talks about 64-bit longs on x86.

I understand that __LP64__ and the idea that there are two reasonable
ABIs most (one 32-bit and one 64-bit) is appealing, but it's not true.
 In the case of PowerPC, it does look like they weren't ABI-specific
macros, but MIPS's were.  If nothing else, you make MIPS headers more
inconsistent with themselves, where most of them are
ABI-conditionalized and now some are instead LP64-centric.

It seems like your end goal is probably consolidating these headers,
which I would like, too, but please attempt to allow for more
variation than just "longs are 32-bit and pointers are 32-bit,
otherwise longs are 64-bit and pointers are 64-bit."  We're trying to
do the right thing with MIPS in terms of supporting multiple valid
ABIs on a single port, something which is a lot harder when people
restructure these critical headers without even asking us whether
there are any evident problems; even if 'make universe', for instance,
were enough, it leaves out some ABIs, and it certainly leaves out
future plans wrt ABIs.

Thanks,
Juli.