https://bugs.winehq.org/show_bug.cgi?id=45199
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Many applications and games |Many applications and games |fail to start/crash after |fail to start/crash after |compiling wine with gcc |compiling wine with gcc |8.1.0 and -O2 |8.1.0 and -O2 (GOT/PIC | |register load code now | |emitted at function entry, | |missing hotpatch | |signatures)
--- Comment #30 from Anastasius Focht focht@gmx.net --- Hello folks,
there is not much choice here since the change in gcc optimization is perfectly valid. Of course it harms now if the function being hotpatched has the GOT/PIC register load code emitted directly at the start of function entry. Most detour/hookers/patchers can't deal with this kind of entry point code. This is usually mitigated by using 'ms_hook_prologue' attribute.
You could either collect all the offenders that have no hotpatch entry point and send in patches that add DECLSPEC_HOTPATCH or use a "no-PIC" build of Wine.
I've built and run Wine with '-fno-PIC' by default since several years. The GOT/PIC register usage in prolog code is incompatible with multiple copy protection/DRM schemes (bug 37540, bug 4666 for example) - even hotpatch doesn't help here, see my explanations. Yes, it can be partially mitigated by emitting syscall thunks for native API (Wine-Staging has some experimental patches) but this won't work for non-native/upper layer API.
I guess you could start with a list like comment #11 (apps that make use of 'libtcmalloc') and send in patches that add DECLSPEC_HOTPATCH as needed.
Regards