-
Notifications
You must be signed in to change notification settings - Fork 390
trace: add barebones ptrace setup #4401
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -227,10 +227,11 @@ impl rustc_driver::Callbacks for MiriCompilerCalls { | |
} else { | ||
let return_code = miri::eval_entry(tcx, entry_def_id, entry_type, &config, None) | ||
.unwrap_or_else(|| { | ||
#[cfg(target_os = "linux")] | ||
miri::register_retcode_sv(rustc_driver::EXIT_FAILURE); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why is this done here but not all the other places where we There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It seems to have something to do with the way There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I think you should be able to remove the random Or does ptrace halt execution on an unwind? It should just resume execution then to let the program run its normal course. |
||
tcx.dcx().abort_if_errors(); | ||
rustc_driver::EXIT_FAILURE | ||
}); | ||
|
||
std::process::exit(return_code); | ||
} | ||
|
||
|
@@ -722,6 +723,8 @@ fn main() { | |
} else { | ||
show_error!("-Zmiri-native-lib `{}` does not exist", filename); | ||
} | ||
} else if arg == "-Zmiri-force-old-native-lib-mode" { | ||
miri_config.force_old_native_lib = true; | ||
} else if let Some(param) = arg.strip_prefix("-Zmiri-num-cpus=") { | ||
let num_cpus = param | ||
.parse::<u32>() | ||
|
@@ -792,6 +795,16 @@ fn main() { | |
|
||
debug!("rustc arguments: {:?}", rustc_args); | ||
debug!("crate arguments: {:?}", miri_config.args); | ||
#[cfg(target_os = "linux")] | ||
if !miri_config.native_lib.is_empty() && !miri_config.force_old_native_lib { | ||
// FIXME: This should display a diagnostic / warning on error | ||
// SAFETY: If any other threads exist at this point (namely for the ctrlc | ||
// handler), they will not interact with anything on the main rustc/Miri | ||
// thread in an async-signal-unsafe way such as by accessing shared | ||
// semaphores, etc.; the handler only calls `sleep()` and `exit()`, which | ||
// are async-signal-safe, as is accessing atomics | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is sounds like this relying on the ctrlc internal implementation details that could change any time...? I also have no clue why we are talking about threads here, but that may be because There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I find it somewhat hard to imagine how the ctrlc handler could realistically be changed to act in ways that may break the safety invariants for signal safety, but for clarity I'll add a better safety comment for There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The main point is that I don't think it even matters what the ctrlc handler does. I think you misunderstood the safety requirements of |
||
let _ = unsafe { miri::init_sv() }; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why do we just ignore errors here...? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If it errored and the sv process failed to init, then we catch that when calling There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Are you saying we dynamically fall back to calling native code without fine-grained tracing if the setup fails? That makes sense, but having a
If you have confusing things like EDIT: There actually is a FIXME, fair. I think I'd have rather seen this staged a bit differently but that's getting into very subjective territory. ;) |
||
} | ||
run_compiler_and_exit( | ||
&rustc_args, | ||
&mut MiriCompilerCalls::new(miri_config, many_seeds, genmc_config), | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This allocates the buffer for these pages twice... that seems rather unnecessary.