[PATCH 0/26] MR8026: Draft: RFC: Running wine with AddressSanitizer
Please see: https://marc.info/?l=wine-devel&m=174715050805731 as well as the commit messages for more information. -- This merge request has too many patches to be relayed via email. Please visit the URL below to see the contents of the merge request. https://gitlab.winehq.org/wine/wine/-/merge_requests/8026
grrr, i forgot one thing in the email. all the asan runtime does is basically reading and writing the shadow memory. crossing the unix call boundary just to read/write memory seems to costly, so the same code is compiled once for each side. this is done by putting it in headers then include them from PE and unix. i don't know if there is a better option. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8026#note_103156
It's probably not a good idea to add asan exports unconditionally: it might conflict with userland apps for example. It's probably better to add `__asan_` thunks to winecrt0, which will discover corresponding ntdll functions via some hidden channel and dispatch to them as necessary. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8026#note_103208
On Tue May 13 21:20:04 2025 +0000, Jinoh Kang wrote:
It's probably not a good idea to add asan exports unconditionally: it might conflict with userland apps for example. It's probably better to add `__asan_` thunks to winecrt0, which will discover corresponding ntdll functions via some hidden channel and dispatch to them as necessary. For DLLs that don't link to winecrt0 due to -nostartfiles, I'm guessing we could add the thunk source directly to SOURCES. Either that, or we could make our own asan thunk static library (like `clang_rt.asan_dll_thunk-i386.lib` but our own).
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/8026#note_103209
participants (2)
-
Jinoh Kang (＠iamahuman) -
Yuxuan Shui (＠yshui)