winebuild ppc

[Josh DuBois]

Hi -

       Sorry for the delay - hard-drive died.

       Well, on the ppc it seems that CRITICAL_SECTIONS which are
initialized (they
get set to CRITICAL_SECTION_INIT a lot) fairly reliably get put on
2-byte
boundaries.  I am not certain why this is the case.  I could perhaps try
to change
all the instances of initialized critial sections to have their data
copied into
them during an init routine, but that seems like yet another big
weirdness.  Or
maybe I can convince the compiler to stop aligning them strangely in the
first
place.

      The problem is that the instructions to implement Interlocked*
functions on
the ppc require the destination of a store to be 4-byte aligned (so I
want to align
the LockCount member).  I'm not sure, actually, how to be certain that
regular
int's passed to these functions will be aligned, but I havn't seen
problems (yet)
other than with the funny alignment of the CRITICAL_SECTION structs.

      You're absolutely right about the gcc'ism, though.  At the very
least, it
needs to be #ifdef'd.

                 Josh.


Ulrich Weigand wrote:

> Josh DuBois wrote:
>
> > @@ -3396,7 +3428,7 @@
> >      HANDLE OwningThread;
> >      HANDLE LockSemaphore;
> >      ULONG_PTR SpinCount;
> > -} RTL_CRITICAL_SECTION, *PRTL_CRITICAL_SECTION;
> > +} __attribute__ ((aligned (4))) RTL_CRITICAL_SECTION, *PRTL_CRITICAL_SECTION;
>
> Why?  The default alignment of this struct is 4 anyway
> (as all its members have a default alignment of 4 ...)
>
> The only situation where a RTL_CRITICAL_SECTION could
> conceivably be not aligned to 4 would be if if were
> embedded into a packed struct.  In this case, however,
> the aligned attribute wouldn't help either AFAIK.
>
> (Additionally, the gcc'ism will annoy Patrik ;-/)
>
> Bye,
> Ulrich
>
> --
>   Dr. Ulrich Weigand
>   weigand at informatik.uni-erlangen.de