[PATCH 1/5] random: Don't assume that _WIN64 implies x86_64
martin at martin.st
Sun Mar 25 21:13:24 CEST 2018
On Sun, 25 Mar 2018, Jussi Kivilinna wrote:
> On 22.03.2018 23:05, Martin Storsjö wrote:
>> On Thu, 22 Mar 2018, Jussi Kivilinna wrote:
>>> On 22.03.2018 10:56, Martin Storsjö wrote:
>>>> This fixes building this file for windows on aarch64.
>>>> Signed-off-by: Martin Storsjö <martin at martin.st>
>>> Thanks for the patches. There is few generic things that needs to be done
>>> before these can be applied:
>>> - Check signing off DCO part in doc/HACKING
>> Thanks - this should done now, hopefully the signatures should be fine even though I don't have a really proper mail+PGP setup.
> I'd also need to verify the signed DCO, so you would need to export
> your public key (maybe by send it to key-server).
Ah, right - that should be done now, and I'm finding it on a few public
search interfaces on the web.
> Thanks, I managed to build clang/mingw tools and libgcrypt with them.
Ok, that's great.
> However, I did not have as much luck with wine. Current git upstream
> builds fine, and I managed to manually apply patch . Yet any attempt
> to run aarch64/win64/PE executable on native aarch64 yields some wine
> assert failure prints and wine refuses to start up :( Even less luck on
> qemu-aarch64 chroot over x86_64... wine-aarch64 just segfaults.
Hmm, that doesn't sound too promising. Does it work on its own if you run
e.g. "wine64 cmd", that doesn't load external binaries?
I have a few other patches locally as well that haven't been merged
upstream, that probably also are needed:
These relate to the use of the x18 register. To have things working really
properly, you'd need to use a linux distribution that is built completely
with the -ffixed-x18 flag, to make the compiler avoid touching the x18
register even though it's normally allowed on linux.
Since you probably don't have that (and neither do I), the first of the
two patches adds this flag while building wine (which in itself only helps
as long as wine doesn't call out to other libraries like glibc), and the
second one that tries to restore x18 on calls to public functions, in case
e.g. glibc actually had clobbered it. That works for calls to public
functions, but not e.g. if wine does a callback to user code, or for COM
These aren't enough to guarantee that things will work though (only a full
distribution built with -ffixed-x18 would do), so they aren't merged
upstream. Despite that, for me they are enough to have a lot of code
working. (Code built with MSVC will use x18 a lot, code built with mingw
libraries and compiler-rt uses it a bit less.)
For your case, even though the external binaries themselves might not rely
on x18 all that much, wine and glibc themselves might, and might be broken
by the few places where wine unconditionally sets the register.
Hopefully these two patches fixes the issue you are running into.
More information about the Gcrypt-devel