Re: Is 21.x going to be 64-bit clean?
>>>> "Olivier" == Olivier Galibert
<galibert(a)pobox.com> writes:
> INLINE int
> bit_vector_bit (struct Lisp_Bit_Vector *v, int i)
> {
> unsigned int ui = (unsigned int) i;
>
> return (((v)->bits[ui >> LONGBITS_LOG2] >> (ui &
(LONGBITS_POWER_OF_2 - 1)))
> & 1);
> }
Olivier> While Lisp_Bit_Vector::bits is declared as an int array for alignment
Olivier> purposes, which is arguably a bug but not a real problem (because of
Olivier> the long size preceding it, and the alignment requirements of sizeof),
Olivier> they really are allocated as longs. This code is correct, and I'm
Olivier> sending a patch for the declaration.
My private workspace already has this in lisp.h:
struct Lisp_Bit_Vector
{
struct lrecord_header lheader;
Lisp_Object next;
size_t size;
unsigned long bits[1];
};
typedef struct Lisp_Bit_Vector Lisp_Bit_Vector;
> The end result is that temacs goes off to visit Elvis when it is
> trying to do the dynodump.
Olivier> Dynodump, being sun specific, has afaik never been tested on a 64bits
Olivier> architecture. The problem probably lies there. I don't think anybody
Olivier> here has the required hardware to fix it, so all I can say is good
Olivier> luck. But you can trust the common code for 64bits cleanliness.
There's this code in src/s/sol2.h, which tries to ensure that
dynodump is only used for SunOS 5.5 and earlier.
#undef UNEXEC
#if OS_RELEASE < 56
#define UNEXEC "unexsol2.o"
#else
#define UNEXEC "unexsol2-6.o"
#endif
Georg Nikodym <georgn(a)Canada.Sun.COM> is the authority on getting
dumping to work on Suns, and has a successful build of XEmacs on
Solaris Bleeding-Edge Operating Environment.
Martin