[Bug 38780] AArch64 platforms: register X18 (TEB) must remain reserved for Wine to run 64-bit ARM Windows applications (Distro aarch64 toolchains need '-ffixed-x18' default, loader/libc/userland)

WineHQ Bugzilla wine-bugs at winehq.org
Wed Aug 4 06:23:43 CDT 2021


https://bugs.winehq.org/show_bug.cgi?id=38780

--- Comment #26 from Martin Storsjö <martin at martin.st> ---
To expand on the matter a bit:

In the current state of things (current master around 6.14), things generally
seem to work pretty nicely.

PE modules built in Wine still link against ntdll.dll's NtCurrentTeb(), and
that doesn't exist on actual Windows. This means that e.g. test executables
built in Wine don't run on real Windows.

It's trivial to add a proper inline version of NtCurrentTeb() in winnt.h, e.g.
like this:

+#elif defined(__aarch64__) && defined(__MINGW32__) && !defined(_NTSYSTEM_)
+static FORCEINLINE struct _TEB * WINAPI NtCurrentTeb(void)
+{
+    struct _TEB *teb;
+    __asm__("mov %0, x18" : "=r" (teb));
+    return teb;
+}

However this still fails when there's ELF code involved, e.g. an ELF
winemenubuilder.exe can call a system API which clobbers x18 and then go on and
call a PE DLL which expects to have a pristine x18 in place.

So for all things that are converted entirely to PE, things work great, and for
cases Where PE modules call ELF modules, things work great. Things don't work
when ELF modules call PE modules.

So the non-inlined NtCurrentTeb() manages to avoid many issues relating to this
in practice, but it would be great to use an inline NtCurrentTeb() for test
executables at least.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.


More information about the wine-bugs mailing list