On Sat, Jul 7, 2018 at 1:09 AM Zebediah Figura z.figura12@gmail.com wrote:
On 07/07/18 00:16, Alex Henrie wrote:
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=45199 Signed-off-by: Alex Henrie alexhenrie24@gmail.com
dlls/msvcrt/heap.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
Can't we at least wait for a response on the GCC bug first?
Even if the GCC bug were fixed immediately, we would still have to add DECLSPEC_HOTPATCH as needed until all major distributions adopt the next version of GCC. I agree that the situation isn't ideal, but on the plus side, even with the 12 functions identified in bug 45199, the functions that applications try to patch are still less than 1% of the total number of Windows functions.
I also really want to see if there are still problems with applications patching 64-bit functions. There is no particular hotpatch prologue on x64 Windows. Instead, each application parses the first few bytes of the function, replaces them with a jump, and then reproduces the original opcodes at the location it jumps to before jumping back into the original function. The purpose of ms_hook_prologue on x64 is simply to provide some recognizable opcodes that are easy to remove and reproduce somewhere else. Until GCC 8.1, the instructions that GCC emitted by default happened to be recognizable by most 64-bit programs that do hotpatching. But the 8-byte NOP instruction currently emitted by ms_hook_prologue on x64 may still not be generally recognizable.
The Steam Overlay, for example, can deal with eight 0x90 NOPs at the beginning of an x64 function but can't deal with the single 8-byte NOP that GCC currently emits. If other applications also can't deal with the 8-byte NOP then we may be able to convince the GCC developers to change the instructions emitted by ms_hook_prologue on x64 for improved compatibility. (The counterargument would be that since opcode parsing is atomic, if GCC switches from one 8-byte NOP to eight 1-byte NOPs then non-Windows applications that use ms_hook_prologue would have to start locking any thread that attempts to execute a function while it is being patched, to avoid reading from the middle of a recently inserted jump instruction.) But, we won't know what is needed until we get feedback from users about whether or not their 64-bit apps are still broken after adding DECLSPEC_HOTPATCH to them.
-Alex