Filter out items other than non-generic functions and statics in our version of `exported_symbols`
[`#[no_mangle]` on a `use` item](https://docs.rs/brotli-decompressor/2.3.1/src/brotli_decompressor/ffi/mod.rs.html#3-5) can make Miri ICE when compiling a dependency (rust-lang/rust#86261):
```rs
#[no_mangle]
use std::{thread,panic, io, boxed, any, string};
```
<details>
```
error: internal compiler error: compiler/rustc_middle/src/ty/mod.rs:1650:13: item_name: no name for DefPath { data: [DisambiguatedDefPathData { data: Misc, disambiguator: 14 }], krate: crate0 }
thread 'rustc' panicked at 'Box<dyn Any>', compiler/rustc_errors/src/lib.rs:1007:9
stack backtrace:
0: std::panicking::begin_panic
1: std::panic::panic_any
2: rustc_errors::HandlerInner::bug
3: rustc_errors::Handler::bug
4: rustc_middle::ty::context::tls::with_opt
5: rustc_middle::util:🐛:opt_span_bug_fmt
6: rustc_middle::util:🐛:bug_fmt
7: rustc_middle::ty::<impl rustc_middle::ty::context::TyCtxt>::item_name
8: rustc_symbol_mangling::symbol_name_provider
9: rustc_query_impl::<impl rustc_query_system::query::config::QueryAccessors<rustc_query_impl::plumbing::QueryCtxt> for rustc_query_impl::queries::symbol_name>::compute
10: rustc_query_system::query::plumbing::get_query_impl
11: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::symbol_name
12: rustc_middle::middle::exported_symbols::ExportedSymbol::symbol_name_for_local_instance
13: rustc_codegen_ssa:🔙:symbol_export::symbol_name_for_instance_in_crate
14: rustc_codegen_ssa:🔙:linker::exported_symbols
15: <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::fold
16: rustc_codegen_ssa:🔙:linker::LinkerInfo::new
17: rustc_codegen_ssa:🔙:write::start_async_codegen
18: <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_ssa::traits::backend::CodegenBackend>::codegen_crate
19: rustc_interface::passes::QueryContext::enter
20: rustc_interface::queries::Queries::ongoing_codegen
21: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter
22: rustc_span::with_source_map
23: rustc_interface::interface::create_compiler_and_run
24: rustc_span::with_session_globals
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md
note: rustc 1.54.0-nightly (a50d72158 2021-06-08) running on x86_64-unknown-linux-gnu
note: compiler flags: -C embed-bitcode=no -C debuginfo=1 --crate-type lib
note: some of the compiler flags provided by cargo are hidden
query stack during panic:
#0 [symbol_name] computing the symbol for `{misc#14}`
end of query stack
```
</details>
This might be because in #1776, we override the `exported_symbols` query, and our version of `exported_symbols` can return a `use` item which don't have a name if the `use` item is tagged with `#[no_mangle]`, and then:
- `rustc_codegen_ssa:🔙:symbol_export::symbol_name_for_instance_in_crate` is called for for every `exported_symbols`: fb3ea63d9b/compiler/rustc_codegen_ssa/src/back/linker.rs (L1300-L1304)
- it calls `rustc_middle::middle::exported_symbols::ExportedSymbol::symbol_name_for_local_instance`: fb3ea63d9b/compiler/rustc_codegen_ssa/src/back/symbol_export.rs (L412)
- which calls `rustc_symbol_mangling::symbol_name_provider`: fb3ea63d9b/compiler/rustc_middle/src/middle/exported_symbols.rs (L37-L44)
- which calls `item_name`: fb3ea63d9b/compiler/rustc_symbol_mangling/src/lib.rs (L216), which triggers the ICE
It might also be problematic for d39f0c64b8/src/shims/foreign_items.rs (L165) which also uses `item_name`, but Miri cannot compile the dependency, so that code can't be reached.
Therefore, this PR makes `exported_symbols` filter out all items that are not functions or statics, so all items returned will have a name, which avoids the ICE (I have tested it in the https://github.com/jorgecarleitao/arrow2 repository).
(This PR also includes a commit that fixes a small (unrelated) bug for `#[no_mangle]` on associated functions -- I found that because I notice `#[no_mangle]` is supported on associated functions and they should not be filtered out in `exported_symbols`.)
Fixes (when the submodule is bumped) rust-lang/rust#86261.
Report an error if a `#[no_mangle]`/`#[export_name = ...]` function has the same symbol name as a built-in shim
Implements https://github.com/rust-lang/miri/pull/1776#issuecomment-821322605.
The error looks like this:
```
error: found `malloc` symbol definition that clashes with a built-in shim
--> tests/compile-fail/function_calls/exported_symbol_shim_clashing.rs:12:9
|
12 | malloc(0);
| ^^^^^^^^^ found `malloc` symbol definition that clashes with a built-in shim
|
help: the `malloc` symbol is defined here
--> tests/compile-fail/function_calls/exported_symbol_shim_clashing.rs:2:1
|
2 | / extern "C" fn malloc(_: usize) -> *mut std::ffi::c_void {
3 | | //~^ HELP the `malloc` symbol is defined here
4 | | unreachable!()
5 | | }
| |_^
= note: inside `main` at tests/compile-fail/function_calls/exported_symbol_shim_clashing.rs:12:9
```
This does not implement "better error messages than we do currently for arg/ABI mismatches" in https://github.com/rust-lang/miri/pull/1776#issuecomment-821343175 -- I failed to remove all `check_arg_count()` and `check_abi()` (they are still used in `src/shims/intrinsics.rs` and `call_dlsym()`) and they don't receive the name of the shim.
Add support for panicking in the emulated application when unsupported functionality is encountered
This PR fixes#1807 and allows an optional flag to be specified to panic when an unsupported syscall is encountered. In essence, instead of bubbling up an error in the context of the Miri application Miri will panic within the context of the *emulated* application. This feature is desired to allow CI pipelines to determine if a Miri failure is unsupported functionality or actual UB. Please read [this comment](https://github.com/rust-lang/miri/issues/1807#issuecomment-845425076) for the rationale behind this change.
Note: this change does not cover all cases where unsupported functionality errors may be raised. If you search the repo for `throw_unsup_format!` there are many cases that I think are less likely to occur and may still be problematic for some folks.
TODO:
- [x] README documentation on this new flag
- [x] Add tests
In user interface, added a new flag `-Zmiri-isolation-error` which
takes one of the four values -- hide, warn, warn-nobacktrace, and
abort. This option can be used to configure Miri to either abort or
return an error code upon executing isolated op. If not aborted, Miri
prints a warning, whose verbosity can be configured using this flag.
In implementation, added a new enum `IsolatedOp` to capture all the
settings related to ops requiring communication with the
host. Old `communicate` flag in both miri configs and machine
stats is replaced with a new helper function `communicate()` which
checks `isolated_op` internally.
Added a new helper function `reject_in_isolation` which can be called
by shims to reject ops according to the reject_with settings. Use miri
specific diagnostics function `report_msg` to print backtrace in the
warning. Update it to take an enum value instead of a bool, indicating
the level of diagnostics.
Updated shims related to current dir to use the new APIs. Added a new
test for current dir ops in isolation without halting machine.
Throw UB if f*_fast intrinsic called with non-finite value
Calling these intrinsics with non-finite values is undefined behaviour, since they result in `f*` intrinsics in LLVM with the `fast` flag, and `fast` math on non-finite values results in `poison` values. (technically LLVM only considers it UB upon _using_ the value, but that shouldn't make much of a difference)
Add simple data-race detector
Partially fixes data-race detection, see #1372, based on Dynamic Race Detection for C++11
- This does not explore weak memory behaviour, only exploring one sequentially consistent ordering.
- Data-race detection is only enabled after the first thread is created, so should have minimal overhead for non-concurrent execution.
- ~~Does not attempt to re-use thread id's so creating and joining threads lots of time in an execution will result in the vector clocks growing in size and slowing down program execution~~ It does now
std now looks up `getrandom` and `statx` with `dlsym` before attempting
to use `syscall(SYS_.., ..)`.
It also now passes all arguments as a machine-sized word, instead of
their original types.
Rustc removed the target wrapper and exposed the target directly.
Result of running:
find . -type f -exec sed -i -e 's/target\.target\([)\.,;]\)/target\1/g' {} \;
Plus one manual edit of the rust-version file
The `backtrace-rs` crate can use this to implement
`Frame::symbol_address`, which is used to skip frames
above the call to `Backtrace::capture` on the stack.
The function pointer will not be useable for comparison purposes if the
function is generic, as CTFE creates a new function pointer for each
cast of a (monomorphized) generic function. However, this already
affects code running under Miri, and isn't a problem for `backtrace-rs`
(which only casts a non-generic function).
I've added logic to allow `MiriFrame` to have either 4 or 5 fields - if
a 5th field is present, we write the function pointer to it.
