-
-
Notifications
You must be signed in to change notification settings - Fork 331
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Building libfuzzer_stb_image on Windows #1652
Comments
The problem is in libafl_targets. I get the same problem when I try to build it on its own or when trying to build other crates that depend on it (e.g. libafl_frida) |
This H file comes from the LLVM includes. By default, they are not added to the INCLUDE path. If I add them using CFLAGS, the compilation fails, as MSVC's cl.exe can't process the LLVM includes. I'd appreciate some help in setting this correctly. |
yes i know what causes it. i'll quickly fix |
well, the problem i thought was the cause is not related. |
I downloaded LLVM-17.0.1-win64.exe from Releases. I first installed it in Program Files. Then I saw that the space in the path causes problems in CFLAGS. So I copied it over to c:\LLVM and updated the PATH. How should the integration between msvc and llvm work? |
it's clang that is called from build.rs to compile the stuff not cl.exe |
I can clearly see it is cl.exe that is called. Please see the error print above. When I build libafl_targets by itself, it compiles 4 files (common, coverage, libcmp, windows_asan) using cl.exe and they are compiled successfully. When I build libafl_frida, it tries to build sancov_cmp.c using cl.exe. When I add LLVM headers it produces loads of warnings and errors like: --- stderr error occurred: Command "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\bin\HostX64\x64\cl.exe" "-nologo" "-MD" "-O2" "-Z7" "-Brepro" "-IC:\LLVM\lib\clang\17\include" "-DSANCOV_CMPLOG=1" "-DCMP_MAP_SIZE=65536" "-DAFLPP_CMPLOG_MAP_W=65536" "-DAFLPP_CMPLOG_MAP_H=32" "-DCMPLOG_MAP_W=65536" "-DCMPLOG_MAP_H=32" "-FoC:\LibAFL\fuzzers\frida_libpng\target\release\build\libafl_targets-e5d08c87abdadb46\out\src\sancov_cmp.o" "-c" "src\sancov_cmp.c" with args "cl.exe" did not execute successfully (status code exit code: 2). |
I ran unix2dos on all H files in the LLVM include |
i think the problem comes from unix2dos. |
I thought it was needed because of the newlines. But I have reinstalled LLVM and now it has Linux end of lines. Regardless, I see the same behavior - cl.exe is run and not clang. And cl.exe does not like clang's headers. How is it supposed to work? Where should the compiler be selected? Maybe I need to reinstall the cc crate of something like this? |
cl.exe is used to compile the llvm pass into a dll then clang is used to compile the fuzzer |
if the failure is in libafl_targets then yes it's all about cl.exe
what's the error if you don't use dos2unix? are you perhaps using cygwin or msys2? If so you should try this with powershell because i never tested this on cygwin or msys2 |
honestly i don't know what is the cause. |
how did you install cl.exe |
cl.exe comes from Visual Studio I had installed before installing LLVM. |
yes because of common_interface_defs.h which is required by frida build. but that one also works in windows CI. |
can you update your visual studio to 2022 and see if it fixes it? |
I confirm that installing VS 2022 resolves the compilation issue. VS2022 comes with the required files and we don't need to add external LLVM. |
Unfortunately, not everything has been resolved. After updating to VS 2022 warning: The following warnings were emitted during compilation: warning: In file included from ./harness.c:10: error: could not compile |
i think #981 broke it |
can you add "libfuzzer_define_run_driver" to libafl_target's feature in libfuzzer_stb_image/Cargo.toml to see if it is fixed? |
Added, but it did not resolve the issue. When I look at the code, I see no implementation of LLVMFuzzerRunDriver in libfuzzer.c of libafl_targets, just its declaration. The linker can't find a library where the function is implemented. |
i got it. |
IMPORTANT
main
branchThank you for making LibAFL better!
Describe the bug
I'm new to LibAFL and am interested in the Windows setup. I followed the instructions, installed Rust, clang, and LLVM (17.0.4). LLVM's bin directory is in the PATH. Next, I tried to build a fuzzer that is supposed to work on Windows, libfuzzer_stb_image. The build fails. I would appreciate having a short tutorial what can be run on Windows as of now and if there are any additional steps to get it working.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The fuzzer builds successfully.
Screen output/Screenshots
Compiling libfuzzer_stb_image v0.11.1 (C:\LibAFL\fuzzers\libfuzzer_stb_image)
error: failed to run custom build command for
libafl_targets v0.11.1 (C:\LibAFL\libafl_targets)
Caused by:
process didn't exit successfully:
C:\LibAFL\fuzzers\libfuzzer_stb_image\target\release\build\libafl_targets-0f4bc85774200502\build-script-build
(exit code: 1)--- stdout
cargo:rerun-if-env-changed=LIBAFL_EDGES_MAP_SIZE
cargo:rerun-if-env-changed=LIBAFL_CMP_MAP_SIZE
cargo:rerun-if-env-changed=LIBAFL_AFLPP_CMPLOG_MAP_W
cargo:rerun-if-env-changed=LIBAFL_AFLPP_CMPLOG_MAP_H
cargo:rerun-if-env-changed=LIBAFL_CMPLOG_MAP_W
cargo:rerun-if-env-changed=LIBAFL_CMPLOG_MAP_H
cargo:rerun-if-env-changed=LIBAFL_ACCOUNTING_MAP_SIZE
cargo:rerun-if-changed=src/sancov_cmp.c
cargo:rustc-link-arg=--undefined=__sanitizer_weak_hook_memcmp
cargo:rustc-link-arg=--undefined=__sanitizer_weak_hook_strncmp
cargo:rustc-link-arg=--undefined=__sanitizer_weak_hook_strncasecmp
cargo:rustc-link-arg=--undefined=__sanitizer_weak_hook_strcmp
cargo:rustc-link-arg=--undefined=__sanitizer_weak_hook_strcasecmp
TARGET = Some("x86_64-pc-windows-msvc")
OPT_LEVEL = Some("3")
HOST = Some("x86_64-pc-windows-msvc")
cargo:rerun-if-env-changed=CC_x86_64-pc-windows-msvc
CC_x86_64-pc-windows-msvc = None
cargo:rerun-if-env-changed=CC_x86_64_pc_windows_msvc
CC_x86_64_pc_windows_msvc = None
cargo:rerun-if-env-changed=HOST_CC
HOST_CC = None
cargo:rerun-if-env-changed=CC
CC = None
cargo:rerun-if-env-changed=CRATE_CC_NO_DEFAULTS
CRATE_CC_NO_DEFAULTS = None
CARGO_CFG_TARGET_FEATURE = Some("fxsr,sse,sse2")
DEBUG = Some("true")
cargo:rerun-if-env-changed=CFLAGS_x86_64-pc-windows-msvc
CFLAGS_x86_64-pc-windows-msvc = None
cargo:rerun-if-env-changed=CFLAGS_x86_64_pc_windows_msvc
CFLAGS_x86_64_pc_windows_msvc = None
cargo:rerun-if-env-changed=HOST_CFLAGS
HOST_CFLAGS = None
cargo:rerun-if-env-changed=CFLAGS
CFLAGS = Some("")
running: "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\bin\HostX64\x64\cl.exe" "-nologo" "-MD" "-O2" "-Z7" "-Brepro" "-DSANCOV_CMPLOG=1" "-DCMP_MAP_SIZE=65536" "-DAFLPP_CMPLOG_MAP_W=65536" "-DAFLPP_CMPLOG_MAP_H=32" "-DCMPLOG_MAP_W=65536" "-DCMPLOG_MAP_H=32" "-FoC:\LibAFL\fuzzers\libfuzzer_stb_image\target\release\build\libafl_targets-796f3221e0432581\out\src\sancov_cmp.o" "-c" "src\sancov_cmp.c"
sancov_cmp.c
src\sancov_cmp.c(9): fatal error C1083: Cannot open include file: 'sanitizer/common_interface_defs.h': No such file or directory
exit code: 2
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: