[PATCH] D115103: Leak Sanitizer port to Windows

[Clemens Wasser via Phabricator via cfe-commits]

clemenswasser added a comment.

I am currently unable to progress as all of my interceptors are not working.
The interceptors are failing, because the `GetInstructionSize` function fails.
For example, the `CreateThread` Win32 function starts on my Windows 11 installation with `4c 8b dc mov r11,rsp` (in little-endian hex: `0xdc8b4c`).
I get this exact value when using the Visual Studio Watch Window with the expression: `0x00FFFFFF & *(uint32_t*)address` while debugging `GetInstructionSize`.
This was then verified by me again in the Visual Studio Disassembly View of `CreateThread` and a third time via this simple test program:

  #include <Windows.h>
  #include <stdio.h>
  #include <string>
  int main() {
    auto* ptr = CreateThread;
    printf("CreateThread: %p\n", ptr);
    printf("CreateThread first bytes: %s\n", std::to_string(*(int*)ptr).c_str());
  }

This exact instruction is correctly handled by the following switch in `GetInstructionSize`:

  switch (0x00FFFFFF & *(u32*)address) {
    ...
    case 0xdc8b4c:    // 4c 8b dc : mov r11, rsp
      return 3;

But `GetInstructionSize` never returns 3 as the switch condition reads `0xdc8bcc` from address which is != `0xdc8b4c` and instead encodes:

  0:  cc                      int3
  1:  8b dc                   mov    ebx,esp

I don't really understand why this would read this **obviously wrong** value when my similar test program reads it correctly.
Does anyone of you know why this might be happening and how I could fix this?
(BTW. Asan also intercepts CreateThreads and that seems to work...)


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D115103/new/

https://reviews.llvm.org/D115103