[PATCH 1/5] random: Don't assume that _WIN64 implies x86_64

[Martin Storsjö]

Hei,

On Sun, 25 Mar 2018, Jussi Kivilinna wrote:

> Moi,
>
> On 22.03.2018 23:05, Martin Storsjö wrote:
>> Moikka,
>>
>> 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 [2]. 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:

- https://source.winehq.org/patches/data/135165
- https://source.winehq.org/patches/data/137759

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 
interfaces.

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.

// Martin