[PATCH] D115103: Leak Sanitizer port to Windows
Clemens Wasser via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Sat Feb 18 10:17:33 PST 2023
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
More information about the cfe-commits
mailing list