Hello SBCL developers,
I've just found that SBCL compiler assumes XMM registers to be untouched
by alloc_tramp (by gencgc.c:alloc). While it might be a realistic
assumption if the code in alloc() contained a couple of syscalls, it is
not really guaranteed by sysv calling convention, as far as I know:
XMM0-XMM7, at least, are callee-saved, and they may be clobbered by any
library function (and even by our own SBCL runtime code, if GCC ever
decides to use SSE2 instructions while translating it).
If the underlying assumption is an idea like "syscalls don't affect FPU
state", there are some reasons to doubt it:
- SSE2 is used for non-FP data as well (we even have our own fast_bzero
in the runtime! what prevents target libc to do the same -- but
without preverving XMM register?)
- Among other things called by alloc(), pthread code may have rather
thick layer running in user-space; pthread_mutex_lock doesn't need to
be a tiny wrapper on some syscall. It is entirely possible that some
of this code will clobber an XMM register in some circumstances.
I found out that it really happens on 64-bit Windows, so I had to patch
alloc_tramp in my port. Relevant commit:
Now I think that hitting the same issue on other platforms is only a
matter of time and luck, so I decided to post this message.
Regards, Anton Kovalenko
+7(916)345-34-02 | Elektrostal' MO, Russia