-
Notifications
You must be signed in to change notification settings - Fork 3
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
Merge DUMPER and DEBUG_DUMPER #1
Comments
(Loved the paper, btw. Differential fuzzing of compilers is something I have a vested interested in, so this was super valuable to me.) |
Thanks for the suggestion. Considering I'm already marking both versions of I have been thinking about something like this though, and it makes getting a pure LLVM IR reproduction easier by not depending on Rust's standard library for printing (but this doesn't work in Miri) use std::ffi::{c_char, c_int}
extern "C" {
fn printf(fmt: *const c_char, ...) -> c_int;
}
fn dump_var(...) {
printf("...", var...);
} |
One option here would be something like fn print_i32(x: i32) {
extern "C" {
fn printf(fmt: *const core::ffi::c_char, ...) -> core::ffi::c_int;
}
if cfg!(miri) {
println!("{x}");
} else {
unsafe { printf(b"%d\n\0".as_ptr().cast(), x); }
}
} |
Or probably this is better to avoid relying on dead code elimination: #[cfg(not(miri))]
fn print_i32(x: i32) {
extern "C" {
fn printf(fmt: *const core::ffi::c_char, ...) -> core::ffi::c_int;
}
unsafe { printf(b"%d\n\0".as_ptr().cast(), x); }
}
#[cfg(miri)]
fn print_i32(x: i32) {
println!("{x}");
} |
You could also pass it a Also, using a dyn trait would probably improve your build times, I think? |
Miri doesn't do optimizations, those are only relevant for the LLVM backend. |
If the option to not use the standard library is added, I could use If you accept contributions, I could implement this BTW, congrats on an amazing project and paper. |
From the thesis paper:
Have you considered merging the two dumper functions? Something like this:
The global variable would be set in main at runtime. Since the programs are guaranteed to be deterministic, you're guaranteed to get the same bugs for both branches. Since dump_var is already marked as
#[inline(never)]
, the compiler would never optimize the checks away. The cost would be an additional always-predicted branch, which doesn't sound too bad.The text was updated successfully, but these errors were encountered: