unaligned access bug in winspool on sparc

[Eric Frias]

Juan Lang a écrit :
> Yikes.  That's a bad one.  The trouble is MS loves
> this sort of return value.  Even if the dll itself
> doesn't dereference an unaligned pointer, the caller
> might depending on how things are layed out.  The
> trouble is i386 allows unaligned memory access, so we
> don't see this sort of thing.

I did some more reading, and found there's a way to get the kernel to
install a handler for unaligned accesses which will synthesize the unaligned
access with two aligned accesses, and then jump back to the original point
in the code.  It's slow, but you only pay the price if you do an unaligned
access, where we would currently crash.  The code to enable this handler is
nice and simple:
    asm("ta 6"); /* 6 == ST_FIX_ALIGN defined in sys/trap.h */
I tossed this code in SIGNAL_Init() in signal_sparc.c, and it prevented the
crash (when I tested, disabling my previous fix).

Since it sounds like there may be more of these bugs lurking deep within
wine, it seems like the best solution would be to have this automatic code
enabled so the application doesn't crash, but to find a way to report it
with ERR or WARN so the problem can be fixed -- even on i386, aligned memory
reads should be faster (I think).

I don't know if there's an easy way to print a message and then jump to the
system's FIX_ALIGN handler.  I did find some code that is supposed to do the
same thing as the system's handler:
http://groups.google.com/groups?selm=D9to5q.531%40beaver.cs.washington.edu&rnum=1
which could be useful if it wasn't possible to chain to the system's
handler.

Do you feel it's reasonable just to turn on ST_FIX_ALIGN, which *could* mask
errors both in wine and in the user's code?

Eric