Re: Pkgsrc patches: patch-ae

[Greg Troxel]

address@hidden (Ludovic Courtès) writes:

> Greg Troxel <address@hidden> writes:
>
>> This just adds defines for more platforms, plus fixes a comment typo.
>>
>> $NetBSD: patch-ae,v 1.13 2007/07/20 00:09:22 gdt Exp $
>>
>> support for NetBSD/alpha, NetBSD/sparc64, and NetBSD/x86_64
>>
> I'm unclear about some of the changes below.
>
>> -# if defined(__NetBSD__) && defined(__sparc__)
>> +# if defined(__NetBSD__) && (defined(__sparc__) || defined(__sparc_v9__))
>
> Two questions:
>
>   1. Isn't `__sparc__' defined on V9?  On GNU/Linux, it seems that it is
>      defined on both V9 and V8, so no special treatment is required.

I tested on both NetBSD 4-stable on an ultra2, and on 3-stable on an
ultra5.  Both had __sparc__ defined.  On the ultra2, I built guile from
pkgsrc without this patch, and then did 'make check' and it passed.  So
I'd say the __sparc_v9__ can be safely omitted.

But, I'm nervous that 64-bit sparc and 32-bit sparc aren't the same
thing, and don't necessarily have the same alignment rules and sizes.

>   2. Unless I'm mistaken, this is equivalent to
>
>        #if (defined(__NetBSD__) && (defined(__sparc__))) || 
> (defined(__sparc_v9__))
>
>      while this should probably be:
>
>        #if defined(__NetBSD__) && (defined(__sparc__) || 
> (defined(__sparc_v9__)))

Sorry, I don't follow this at all - it looks fine to me.  But it's moot,
as the change can be skipped.

>> +# if defined(__NetBSD__) && defined(__x86_64__)
>> +#   define X86_64
>> +#   define NETBSD
>> +#   define mach_type_known
>> +# endif
>
> [...]
>
>> +# ifdef X86_64
>> +#   define MACH_TYPE "X86_64"
>> +#   define ALIGNMENT 8
>> +#   define ALIGN_DOUBLE
>> +#   define CPP_WORDSZ 64
>> +#   ifdef NETBSD
>> +#   define OS_TYPE "NETBSD"
>> +#   endif
>> +#   if defined(NETBSD)
>> +#   define HEURISTIC2
>> +    extern char etext;
>> +#   define DATASTART ((ptr_t)(&etext))
>> +#   endif
>> +#   endif
>
> Strangely enough, we don't have `LINUX && __x86_64__' either.
> Interestingly, of these constants, it seems that Guile uses only
> `HEURISTIC2'.  For instance, Guile's GC gets the alignment constraint
> through the definition of `SCM_STACKITEM'.

There's a comment in gc_os_dep.c that says ALIGNMENT needs to be
defined.  The other arches seem to define it. (Not arguing that it's
used.)

I suppose the challenge is to figure out how/why guile works on Linux
amd64 systems.

> Hence my question: didn't the NetBSD/i386 support suffice on x86-64?
> What exact problem did it solve?

I don't know - I can inquire.  But amd64 (as we call it) is a different
processor architecture, with a different pointer size, so I don't see
how the i386 support would apply.  I would not expect the i386
preprocessor symbols to be defined, but I don't have a netbsd/amd64
system (I really should set one up).

Not sure this is relevant, but: On NetBSD, an amd64 system is all 64-bit
native code.  If there's i386 compat code, it's in /emul/netbsd32.  The
"lib64" convention is not used at all.

> The other bits are indeed applicable.

Thanks - I'll adjust the patch when there's a new release, dropping
whatever you merged and also the sparc v9.