https://bugs.winehq.org/show_bug.cgi?id=38780
--- Comment #19 from Martin Storsjö martin@martin.st --- (In reply to Zebediah Figura from comment #18)
(In reply to Martin Storsjö from comment #17)
(In reply to Zebediah Figura from comment #16)
(In reply to Martin Storsjö from comment #15)
I guess it could be doable to back it up in the prologue and restore it the epilogue in functions on non-windows that are marked with the ms_abi attribute. For restoring/setting it up around WINAPI callbacks, where would the compiler get the value to set into x18?
From the spilled location?
When the windows code calls a wine function (compiled for linux, with ms_abi attribute on the entry point), this prologue can indeed treat it as a callee-save register and back it up.
This function then goes on to call other host environment functions (glibc etc) which clobber x18, and a number of other wine-internal functions, which don't have the ms_abi attribute set, which don't back up and restore x18 (which could be garbage at this point anyway). Deep in this call stack, some function calls a WINAPI callback. How does that nested context find what the real x18 value was on entry into the wine code, several stack frames deeper?
Ah, yes, that would sort of rule out that approach, then.
Currently I'm running with this patch: https://source.winehq.org/patches/data/137759
This pretty much gets the same effect as the suggested compiler handling for prologues/epilogues, but without compiler support - but it doesn't fix callbacks either. This (together with https://source.winehq.org/patches/data/135165) has been a good enough workaround for me so far though.