rust/src/librustc_codegen_llvm/mir/mod.rs

653 lines
26 KiB
Rust
Raw Normal View History

// Copyright 2012-2014 The Rust Project Developers. See the COPYRIGHT
// file at the top-level directory of this distribution and at
// http://rust-lang.org/COPYRIGHT.
//
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
// option. This file may not be copied, modified, or distributed
// except according to those terms.
rustc: Tweak funclet cleanups of ffi functions This commit is targeted at addressing #48251 by specifically fixing a case where a longjmp over Rust frames on MSVC runs cleanups, accidentally running the "abort the program" cleanup as well. Added in #46833 `extern` ABI functions in Rust will abort the process if Rust panics, and currently this is modeled as a normal cleanup like all other destructors. Unfortunately it turns out that `longjmp` on MSVC is implemented with SEH, the same mechanism used to implement panics in Rust. This means that `longjmp` over Rust frames will run Rust cleanups (even though we don't necessarily want it to). Notably this means that if you `longjmp` over a Rust stack frame then that probably means you'll abort the program because one of the cleanups will abort the process. After some discussion on IRC it turns out that `longjmp` doesn't run cleanups for *caught* exceptions, it only runs cleanups for cleanup pads. Using this information this commit tweaks the codegen for an `extern` function to a catch-all clause for exceptions instead of a cleanup block. This catch-all is equivalent to the C++ code: try { foo(); } catch (...) { bar(); } and in fact our codegen here is designed to match exactly what clang emits for that C++ code! With this tweak a longjmp over Rust code will no longer abort the process. A longjmp will continue to "accidentally" run Rust cleanups (destructors) on MSVC. Other non-MSVC platforms will not rust destructors with a longjmp, so we'll probably still recommend "don't have destructors on the stack", but in any case this is a more surgical fix than #48567 and should help us stick to standard personality functions a bit longer.
2018-02-27 03:59:47 +01:00
use common::{C_i32, C_null};
use libc::c_uint;
2016-12-12 06:19:39 +01:00
use llvm::{self, ValueRef, BasicBlockRef};
2016-12-16 21:25:18 +01:00
use llvm::debuginfo::DIScope;
use rustc::ty::{self, Ty, TypeFoldable, UpvarSubsts};
use rustc::ty::layout::{LayoutOf, TyLayout};
2016-12-17 04:52:20 +01:00
use rustc::mir::{self, Mir};
2016-12-19 00:05:40 +01:00
use rustc::ty::subst::Substs;
use rustc::session::config::FullDebugInfo;
use base;
2017-01-01 00:00:24 +01:00
use builder::Builder;
use common::{CodegenCx, Funclet};
2016-12-16 21:25:18 +01:00
use debuginfo::{self, declare_local, VariableAccess, VariableKind, FunctionDebugContext};
use monomorphize::Instance;
use abi::{ArgAttribute, ArgTypeExt, FnType, FnTypeExt, PassMode};
rustc: Tweak funclet cleanups of ffi functions This commit is targeted at addressing #48251 by specifically fixing a case where a longjmp over Rust frames on MSVC runs cleanups, accidentally running the "abort the program" cleanup as well. Added in #46833 `extern` ABI functions in Rust will abort the process if Rust panics, and currently this is modeled as a normal cleanup like all other destructors. Unfortunately it turns out that `longjmp` on MSVC is implemented with SEH, the same mechanism used to implement panics in Rust. This means that `longjmp` over Rust frames will run Rust cleanups (even though we don't necessarily want it to). Notably this means that if you `longjmp` over a Rust stack frame then that probably means you'll abort the program because one of the cleanups will abort the process. After some discussion on IRC it turns out that `longjmp` doesn't run cleanups for *caught* exceptions, it only runs cleanups for cleanup pads. Using this information this commit tweaks the codegen for an `extern` function to a catch-all clause for exceptions instead of a cleanup block. This catch-all is equivalent to the C++ code: try { foo(); } catch (...) { bar(); } and in fact our codegen here is designed to match exactly what clang emits for that C++ code! With this tweak a longjmp over Rust code will no longer abort the process. A longjmp will continue to "accidentally" run Rust cleanups (destructors) on MSVC. Other non-MSVC platforms will not rust destructors with a longjmp, so we'll probably still recommend "don't have destructors on the stack", but in any case this is a more surgical fix than #48567 and should help us stick to standard personality functions a bit longer.
2018-02-27 03:59:47 +01:00
use type_::Type;
2017-03-17 05:04:41 +01:00
use syntax_pos::{DUMMY_SP, NO_EXPANSION, BytePos, Span};
use syntax::symbol::keywords;
use std::iter;
use rustc_data_structures::bitvec::BitVector;
use rustc_data_structures::indexed_vec::{IndexVec, Idx};
2018-05-08 15:10:16 +02:00
pub use self::constant::codegen_static_initializer;
2016-12-19 01:04:00 +01:00
use self::analyze::CleanupKind;
use self::place::PlaceRef;
use rustc::mir::traversal;
Various improvements to MIR and LLVM IR Construction Primarily affects the MIR construction, which indirectly improves LLVM IR generation, but some LLVM IR changes have been made too. * Handle "statement expressions" more intelligently. These are expressions that always evaluate to `()`. Previously a temporary would be generated as a destination to translate into, which is unnecessary. This affects assignment, augmented assignment, `return`, `break` and `continue`. * Avoid inserting drops for non-drop types in more places. Scheduled drops were already skipped for types that we knew wouldn't need dropping at construction time. However manually-inserted drops like those for `x` in `x = y;` were still generated. `build_drop` now takes a type parameter like its `schedule_drop` counterpart and checks to see if the type needs dropping. * Avoid generating an extra temporary for an assignment where the types involved don't need dropping. Previously an expression like `a = b + 1;` would result in a temporary for `b + 1`. This is so the RHS can be evaluated, then the LHS evaluated and dropped and have everything work correctly. However, this isn't necessary if the `LHS` doesn't need a drop, as we can just overwrite the existing value. * Improves lvalue analysis to allow treating an `Rvalue::Use` as an operand in certain conditions. The reason for it never being an operand is so it can be zeroed/drop-filled, but this is only true for types that need dropping. The first two changes result in significantly fewer MIR blocks being generated, as previously almost every statement would end up generating a new block due to the drop of the `()` temporary being generated.
2016-04-15 02:36:16 +02:00
use self::operand::{OperandRef, OperandValue};
2018-05-08 15:10:16 +02:00
/// Master context for codegenning from MIR.
pub struct FunctionCx<'a, 'tcx:'a> {
2018-01-16 09:31:48 +01:00
instance: Instance<'tcx>,
mir: &'a mir::Mir<'tcx>,
debug_context: debuginfo::FunctionDebugContext,
2017-01-01 08:42:09 +01:00
llfn: ValueRef,
2018-01-05 06:04:08 +01:00
cx: &'a CodegenCx<'a, 'tcx>,
2016-12-20 01:48:41 +01:00
fn_ty: FnType<'tcx, Ty<'tcx>>,
2016-12-20 03:16:36 +01:00
/// When unwinding is initiated, we have to store this personality
/// value somewhere so that we can load it and re-use it in the
/// resume instruction. The personality is (afaik) some kind of
/// value used for C++ unwinding, which must filter by type: we
/// don't really care about it very much. Anyway, this value
/// contains an alloca into which the personality is stored and
/// then later loaded when generating the DIVERGE_BLOCK.
2017-12-01 13:31:47 +01:00
personality_slot: Option<PlaceRef<'tcx>>,
/// A `Block` for each MIR `BasicBlock`
2016-12-12 06:19:39 +01:00
blocks: IndexVec<mir::BasicBlock, BasicBlockRef>,
/// The funclet status of each basic block
cleanup_kinds: IndexVec<mir::BasicBlock, analyze::CleanupKind>,
/// When targeting MSVC, this stores the cleanup info for each funclet
/// BB. This is initialized as we compute the funclets' head block in RPO.
funclets: &'a IndexVec<mir::BasicBlock, Option<Funclet>>,
/// This stores the landing-pad block for a given BB, computed lazily on GNU
/// and eagerly on MSVC.
2016-12-12 06:19:39 +01:00
landing_pads: IndexVec<mir::BasicBlock, Option<BasicBlockRef>>,
/// Cached unreachable block
2016-12-12 06:19:39 +01:00
unreachable_block: Option<BasicBlockRef>,
/// The location where each MIR arg/var/tmp/ret is stored. This is
2017-12-01 13:31:47 +01:00
/// usually an `PlaceRef` representing an alloca, but not always:
/// sometimes we can skip the alloca and just store the value
/// directly using an `OperandRef`, which makes for tighter LLVM
/// IR. The conditions for using an `OperandRef` are as follows:
///
/// - the type of the local must be judged "immediate" by `is_llvm_immediate`
/// - the operand must never be referenced indirectly
/// - we should not take its address using the `&` operator
/// - nor should it appear in a place path like `tmp.a`
/// - the operand must be defined by an rvalue that can generate immediate
/// values
2015-11-03 21:50:04 +01:00
///
/// Avoiding allocs can also be important for certain intrinsics,
/// notably `expect`.
locals: IndexVec<mir::Local, LocalRef<'tcx>>,
/// Debug information for MIR scopes.
scopes: IndexVec<mir::VisibilityScope, debuginfo::MirDebugScope>,
2016-12-19 00:05:40 +01:00
/// If this function is being monomorphized, this contains the type substitutions used.
param_substs: &'tcx Substs<'tcx>,
}
impl<'a, 'tcx> FunctionCx<'a, 'tcx> {
2016-12-19 00:05:40 +01:00
pub fn monomorphize<T>(&self, value: &T) -> T
where T: TypeFoldable<'tcx>
{
self.cx.tcx.subst_and_normalize_erasing_regions(
self.param_substs,
ty::ParamEnv::reveal_all(),
value,
)
2016-12-19 00:05:40 +01:00
}
2018-01-05 06:12:32 +01:00
pub fn set_debug_loc(&mut self, bx: &Builder, source_info: mir::SourceInfo) {
let (scope, span) = self.debug_loc(source_info);
2018-01-05 06:12:32 +01:00
debuginfo::set_source_location(&self.debug_context, bx, scope, span);
}
2016-12-16 21:25:18 +01:00
pub fn debug_loc(&mut self, source_info: mir::SourceInfo) -> (DIScope, Span) {
// Bail out if debug info emission is not enabled.
match self.debug_context {
FunctionDebugContext::DebugInfoDisabled |
FunctionDebugContext::FunctionWithoutDebugInfo => {
2016-12-16 21:25:18 +01:00
return (self.scopes[source_info.scope].scope_metadata, source_info.span);
}
FunctionDebugContext::RegularContext(_) =>{}
}
// In order to have a good line stepping behavior in debugger, we overwrite debug
// locations of macro expansions with that of the outermost expansion site
// (unless the crate is being compiled with `-Z debug-macros`).
2017-07-31 22:04:34 +02:00
if source_info.span.ctxt() == NO_EXPANSION ||
2018-01-05 06:04:08 +01:00
self.cx.sess().opts.debugging_opts.debug_macros {
2017-07-31 22:04:34 +02:00
let scope = self.scope_metadata_for_loc(source_info.scope, source_info.span.lo());
(scope, source_info.span)
} else {
// Walk up the macro expansion chain until we reach a non-expanded span.
2017-08-11 20:34:14 +02:00
// We also stop at the function body level because no line stepping can occur
2017-02-10 03:35:19 +01:00
// at the level above that.
let mut span = source_info.span;
2017-07-31 22:04:34 +02:00
while span.ctxt() != NO_EXPANSION && span.ctxt() != self.mir.span.ctxt() {
if let Some(info) = span.ctxt().outer().expn_info() {
2017-03-17 05:04:41 +01:00
span = info.call_site;
} else {
break;
}
}
2017-07-31 22:04:34 +02:00
let scope = self.scope_metadata_for_loc(source_info.scope, span.lo());
// Use span of the outermost expansion site, while keeping the original lexical scope.
(scope, span)
}
}
// DILocations inherit source file name from the parent DIScope. Due to macro expansions
// it may so happen that the current span belongs to a different file than the DIScope
// corresponding to span's containing visibility scope. If so, we need to create a DIScope
// "extension" into that file.
fn scope_metadata_for_loc(&self, scope_id: mir::VisibilityScope, pos: BytePos)
-> llvm::debuginfo::DIScope {
let scope_metadata = self.scopes[scope_id].scope_metadata;
if pos < self.scopes[scope_id].file_start_pos ||
pos >= self.scopes[scope_id].file_end_pos {
2018-01-05 06:04:08 +01:00
let cm = self.cx.sess().codemap();
let defining_crate = self.debug_context.get_ref(DUMMY_SP).defining_crate;
2018-01-05 06:04:08 +01:00
debuginfo::extend_scope_to_file(self.cx,
scope_metadata,
&cm.lookup_char_pos(pos).file,
defining_crate)
} else {
scope_metadata
}
}
}
enum LocalRef<'tcx> {
2017-12-01 13:31:47 +01:00
Place(PlaceRef<'tcx>),
Operand(Option<OperandRef<'tcx>>),
}
impl<'a, 'tcx> LocalRef<'tcx> {
2018-01-05 06:04:08 +01:00
fn new_operand(cx: &CodegenCx<'a, 'tcx>, layout: TyLayout<'tcx>) -> LocalRef<'tcx> {
if layout.is_zst() {
// Zero-size temporaries aren't always initialized, which
// doesn't matter because they don't contain data, but
// we need something in the operand.
2018-01-05 06:04:08 +01:00
LocalRef::Operand(Some(OperandRef::new_zst(cx, layout)))
} else {
LocalRef::Operand(None)
}
}
}
///////////////////////////////////////////////////////////////////////////
2018-05-08 15:10:16 +02:00
pub fn codegen_mir<'a, 'tcx: 'a>(
2018-01-05 06:04:08 +01:00
cx: &'a CodegenCx<'a, 'tcx>,
2017-01-01 08:42:09 +01:00
llfn: ValueRef,
mir: &'a Mir<'tcx>,
instance: Instance<'tcx>,
sig: ty::FnSig<'tcx>,
) {
2018-01-05 06:04:08 +01:00
let fn_ty = FnType::new(cx, sig, &[]);
debug!("fn_ty: {:?}", fn_ty);
let debug_context =
2018-01-05 06:04:08 +01:00
debuginfo::create_function_debug_context(cx, instance, sig, llfn, mir);
2018-01-05 06:12:32 +01:00
let bx = Builder::new_block(cx, llfn, "start");
if mir.basic_blocks().iter().any(|bb| bb.is_cleanup) {
2018-01-05 06:12:32 +01:00
bx.set_personality_fn(cx.eh_personality());
}
let cleanup_kinds = analyze::cleanup_kinds(&mir);
// Allocate a `Block` for every basic block, except
// the start block, if nothing loops back to it.
let reentrant_start_block = !mir.predecessors_for(mir::START_BLOCK).is_empty();
2018-01-05 06:12:32 +01:00
let block_bxs: IndexVec<mir::BasicBlock, BasicBlockRef> =
mir.basic_blocks().indices().map(|bb| {
if bb == mir::START_BLOCK && !reentrant_start_block {
2018-01-05 06:12:32 +01:00
bx.llbb()
} else {
2018-01-05 06:12:32 +01:00
bx.build_sibling_block(&format!("{:?}", bb)).llbb()
}
}).collect();
// Compute debuginfo scopes from MIR scopes.
2018-01-05 06:04:08 +01:00
let scopes = debuginfo::create_mir_scopes(cx, mir, &debug_context);
rustc: Tweak funclet cleanups of ffi functions This commit is targeted at addressing #48251 by specifically fixing a case where a longjmp over Rust frames on MSVC runs cleanups, accidentally running the "abort the program" cleanup as well. Added in #46833 `extern` ABI functions in Rust will abort the process if Rust panics, and currently this is modeled as a normal cleanup like all other destructors. Unfortunately it turns out that `longjmp` on MSVC is implemented with SEH, the same mechanism used to implement panics in Rust. This means that `longjmp` over Rust frames will run Rust cleanups (even though we don't necessarily want it to). Notably this means that if you `longjmp` over a Rust stack frame then that probably means you'll abort the program because one of the cleanups will abort the process. After some discussion on IRC it turns out that `longjmp` doesn't run cleanups for *caught* exceptions, it only runs cleanups for cleanup pads. Using this information this commit tweaks the codegen for an `extern` function to a catch-all clause for exceptions instead of a cleanup block. This catch-all is equivalent to the C++ code: try { foo(); } catch (...) { bar(); } and in fact our codegen here is designed to match exactly what clang emits for that C++ code! With this tweak a longjmp over Rust code will no longer abort the process. A longjmp will continue to "accidentally" run Rust cleanups (destructors) on MSVC. Other non-MSVC platforms will not rust destructors with a longjmp, so we'll probably still recommend "don't have destructors on the stack", but in any case this is a more surgical fix than #48567 and should help us stick to standard personality functions a bit longer.
2018-02-27 03:59:47 +01:00
let (landing_pads, funclets) = create_funclets(mir, &bx, &cleanup_kinds, &block_bxs);
let mut fx = FunctionCx {
2018-01-16 09:31:48 +01:00
instance,
mir,
llfn,
fn_ty,
2018-01-05 06:04:08 +01:00
cx,
personality_slot: None,
2018-01-05 06:12:32 +01:00
blocks: block_bxs,
unreachable_block: None,
cleanup_kinds,
landing_pads,
funclets: &funclets,
scopes,
locals: IndexVec::new(),
debug_context,
2016-12-19 00:05:40 +01:00
param_substs: {
assert!(!instance.substs.needs_infer());
instance.substs
},
};
let memory_locals = analyze::non_ssa_locals(&fx);
2016-12-19 00:05:40 +01:00
// Allocate variable and temp allocas
fx.locals = {
let args = arg_local_refs(&bx, &fx, &fx.scopes, &memory_locals);
let mut allocate_local = |local| {
let decl = &mir.local_decls[local];
let layout = bx.cx.layout_of(fx.monomorphize(&decl.ty));
assert!(!layout.ty.has_erasable_regions());
if let Some(name) = decl.name {
// User variable
let debug_scope = fx.scopes[decl.source_info.scope];
2018-01-05 06:12:32 +01:00
let dbg = debug_scope.is_valid() && bx.sess().opts.debuginfo == FullDebugInfo;
if !memory_locals.contains(local.index()) && !dbg {
debug!("alloc: {:?} ({}) -> operand", local, name);
2018-01-05 06:12:32 +01:00
return LocalRef::new_operand(bx.cx, layout);
}
debug!("alloc: {:?} ({}) -> place", local, name);
2018-01-05 06:12:32 +01:00
let place = PlaceRef::alloca(&bx, layout, &name.as_str());
if dbg {
let (scope, span) = fx.debug_loc(decl.source_info);
declare_local(&bx, &fx.debug_context, name, layout.ty, scope,
VariableAccess::DirectVariable { alloca: place.llval },
2016-12-16 21:25:18 +01:00
VariableKind::LocalVariable, span);
}
LocalRef::Place(place)
} else {
// Temporary or return place
if local == mir::RETURN_PLACE && fx.fn_ty.ret.is_indirect() {
debug!("alloc: {:?} (return place) -> place", local);
2017-01-01 08:42:09 +01:00
let llretptr = llvm::get_param(llfn, 0);
LocalRef::Place(PlaceRef::new_sized(llretptr, layout, layout.align))
} else if memory_locals.contains(local.index()) {
debug!("alloc: {:?} -> place", local);
2018-01-05 06:12:32 +01:00
LocalRef::Place(PlaceRef::alloca(&bx, layout, &format!("{:?}", local)))
} else {
// If this is an immediate local, we do not create an
// alloca in advance. Instead we wait until we see the
// definition and update the operand there.
debug!("alloc: {:?} -> operand", local);
2018-01-05 06:12:32 +01:00
LocalRef::new_operand(bx.cx, layout)
}
}
};
let retptr = allocate_local(mir::RETURN_PLACE);
iter::once(retptr)
.chain(args.into_iter())
2016-09-26 22:55:07 +02:00
.chain(mir.vars_and_temps_iter().map(allocate_local))
.collect()
};
// Branch to the START block, if it's not the entry block.
if reentrant_start_block {
bx.br(fx.blocks[mir::START_BLOCK]);
}
// Up until here, IR instructions for this function have explicitly not been annotated with
// source code location, so we don't step into call setup code. From here on, source location
// emitting should be enabled.
debuginfo::start_emitting_source_locations(&fx.debug_context);
2016-12-19 01:04:00 +01:00
let rpo = traversal::reverse_postorder(&mir);
let mut visited = BitVector::new(mir.basic_blocks().len());
2018-05-08 15:10:16 +02:00
// Codegen the body of each block using reverse postorder
for (bb, _) in rpo {
visited.insert(bb.index());
2018-05-08 15:10:16 +02:00
fx.codegen_block(bb);
}
// Remove blocks that haven't been visited, or have no
// predecessors.
2016-06-07 20:20:50 +02:00
for bb in mir.basic_blocks().indices() {
// Unreachable block
if !visited.contains(bb.index()) {
2018-05-08 15:10:16 +02:00
debug!("codegen_mir: block {:?} was not visited", bb);
unsafe {
llvm::LLVMDeleteBasicBlock(fx.blocks[bb]);
}
}
}
}
fn create_funclets<'a, 'tcx>(
rustc: Tweak funclet cleanups of ffi functions This commit is targeted at addressing #48251 by specifically fixing a case where a longjmp over Rust frames on MSVC runs cleanups, accidentally running the "abort the program" cleanup as well. Added in #46833 `extern` ABI functions in Rust will abort the process if Rust panics, and currently this is modeled as a normal cleanup like all other destructors. Unfortunately it turns out that `longjmp` on MSVC is implemented with SEH, the same mechanism used to implement panics in Rust. This means that `longjmp` over Rust frames will run Rust cleanups (even though we don't necessarily want it to). Notably this means that if you `longjmp` over a Rust stack frame then that probably means you'll abort the program because one of the cleanups will abort the process. After some discussion on IRC it turns out that `longjmp` doesn't run cleanups for *caught* exceptions, it only runs cleanups for cleanup pads. Using this information this commit tweaks the codegen for an `extern` function to a catch-all clause for exceptions instead of a cleanup block. This catch-all is equivalent to the C++ code: try { foo(); } catch (...) { bar(); } and in fact our codegen here is designed to match exactly what clang emits for that C++ code! With this tweak a longjmp over Rust code will no longer abort the process. A longjmp will continue to "accidentally" run Rust cleanups (destructors) on MSVC. Other non-MSVC platforms will not rust destructors with a longjmp, so we'll probably still recommend "don't have destructors on the stack", but in any case this is a more surgical fix than #48567 and should help us stick to standard personality functions a bit longer.
2018-02-27 03:59:47 +01:00
mir: &'a Mir<'tcx>,
2018-01-05 06:12:32 +01:00
bx: &Builder<'a, 'tcx>,
cleanup_kinds: &IndexVec<mir::BasicBlock, CleanupKind>,
2018-01-05 06:12:32 +01:00
block_bxs: &IndexVec<mir::BasicBlock, BasicBlockRef>)
-> (IndexVec<mir::BasicBlock, Option<BasicBlockRef>>,
IndexVec<mir::BasicBlock, Option<Funclet>>)
{
2018-01-05 06:12:32 +01:00
block_bxs.iter_enumerated().zip(cleanup_kinds).map(|((bb, &llbb), cleanup_kind)| {
match *cleanup_kind {
rustc: Tweak funclet cleanups of ffi functions This commit is targeted at addressing #48251 by specifically fixing a case where a longjmp over Rust frames on MSVC runs cleanups, accidentally running the "abort the program" cleanup as well. Added in #46833 `extern` ABI functions in Rust will abort the process if Rust panics, and currently this is modeled as a normal cleanup like all other destructors. Unfortunately it turns out that `longjmp` on MSVC is implemented with SEH, the same mechanism used to implement panics in Rust. This means that `longjmp` over Rust frames will run Rust cleanups (even though we don't necessarily want it to). Notably this means that if you `longjmp` over a Rust stack frame then that probably means you'll abort the program because one of the cleanups will abort the process. After some discussion on IRC it turns out that `longjmp` doesn't run cleanups for *caught* exceptions, it only runs cleanups for cleanup pads. Using this information this commit tweaks the codegen for an `extern` function to a catch-all clause for exceptions instead of a cleanup block. This catch-all is equivalent to the C++ code: try { foo(); } catch (...) { bar(); } and in fact our codegen here is designed to match exactly what clang emits for that C++ code! With this tweak a longjmp over Rust code will no longer abort the process. A longjmp will continue to "accidentally" run Rust cleanups (destructors) on MSVC. Other non-MSVC platforms will not rust destructors with a longjmp, so we'll probably still recommend "don't have destructors on the stack", but in any case this is a more surgical fix than #48567 and should help us stick to standard personality functions a bit longer.
2018-02-27 03:59:47 +01:00
CleanupKind::Funclet if base::wants_msvc_seh(bx.sess()) => {}
_ => return (None, None)
}
let cleanup;
let ret_llbb;
match mir[bb].terminator.as_ref().map(|t| &t.kind) {
// This is a basic block that we're aborting the program for,
// notably in an `extern` function. These basic blocks are inserted
// so that we assert that `extern` functions do indeed not panic,
// and if they do we abort the process.
//
// On MSVC these are tricky though (where we're doing funclets). If
// we were to do a cleanuppad (like below) the normal functions like
// `longjmp` would trigger the abort logic, terminating the
// program. Instead we insert the equivalent of `catch(...)` for C++
// which magically doesn't trigger when `longjmp` files over this
// frame.
//
// Lots more discussion can be found on #48251 but this codegen is
// modeled after clang's for:
//
// try {
// foo();
// } catch (...) {
// bar();
// }
Some(&mir::TerminatorKind::Abort) => {
let cs_bx = bx.build_sibling_block(&format!("cs_funclet{:?}", bb));
let cp_bx = bx.build_sibling_block(&format!("cp_funclet{:?}", bb));
ret_llbb = cs_bx.llbb();
let cs = cs_bx.catch_switch(None, None, 1);
cs_bx.add_handler(cs, cp_bx.llbb());
// The "null" here is actually a RTTI type descriptor for the
// C++ personality function, but `catch (...)` has no type so
// it's null. The 64 here is actually a bitfield which
// represents that this is a catch-all block.
let null = C_null(Type::i8p(bx.cx));
let sixty_four = C_i32(bx.cx, 64);
cleanup = cp_bx.catch_pad(cs, &[null, sixty_four, null]);
cp_bx.br(llbb);
}
_ => {
2018-01-05 06:12:32 +01:00
let cleanup_bx = bx.build_sibling_block(&format!("funclet_{:?}", bb));
rustc: Tweak funclet cleanups of ffi functions This commit is targeted at addressing #48251 by specifically fixing a case where a longjmp over Rust frames on MSVC runs cleanups, accidentally running the "abort the program" cleanup as well. Added in #46833 `extern` ABI functions in Rust will abort the process if Rust panics, and currently this is modeled as a normal cleanup like all other destructors. Unfortunately it turns out that `longjmp` on MSVC is implemented with SEH, the same mechanism used to implement panics in Rust. This means that `longjmp` over Rust frames will run Rust cleanups (even though we don't necessarily want it to). Notably this means that if you `longjmp` over a Rust stack frame then that probably means you'll abort the program because one of the cleanups will abort the process. After some discussion on IRC it turns out that `longjmp` doesn't run cleanups for *caught* exceptions, it only runs cleanups for cleanup pads. Using this information this commit tweaks the codegen for an `extern` function to a catch-all clause for exceptions instead of a cleanup block. This catch-all is equivalent to the C++ code: try { foo(); } catch (...) { bar(); } and in fact our codegen here is designed to match exactly what clang emits for that C++ code! With this tweak a longjmp over Rust code will no longer abort the process. A longjmp will continue to "accidentally" run Rust cleanups (destructors) on MSVC. Other non-MSVC platforms will not rust destructors with a longjmp, so we'll probably still recommend "don't have destructors on the stack", but in any case this is a more surgical fix than #48567 and should help us stick to standard personality functions a bit longer.
2018-02-27 03:59:47 +01:00
ret_llbb = cleanup_bx.llbb();
cleanup = cleanup_bx.cleanup_pad(None, &[]);
2018-01-05 06:12:32 +01:00
cleanup_bx.br(llbb);
}
rustc: Tweak funclet cleanups of ffi functions This commit is targeted at addressing #48251 by specifically fixing a case where a longjmp over Rust frames on MSVC runs cleanups, accidentally running the "abort the program" cleanup as well. Added in #46833 `extern` ABI functions in Rust will abort the process if Rust panics, and currently this is modeled as a normal cleanup like all other destructors. Unfortunately it turns out that `longjmp` on MSVC is implemented with SEH, the same mechanism used to implement panics in Rust. This means that `longjmp` over Rust frames will run Rust cleanups (even though we don't necessarily want it to). Notably this means that if you `longjmp` over a Rust stack frame then that probably means you'll abort the program because one of the cleanups will abort the process. After some discussion on IRC it turns out that `longjmp` doesn't run cleanups for *caught* exceptions, it only runs cleanups for cleanup pads. Using this information this commit tweaks the codegen for an `extern` function to a catch-all clause for exceptions instead of a cleanup block. This catch-all is equivalent to the C++ code: try { foo(); } catch (...) { bar(); } and in fact our codegen here is designed to match exactly what clang emits for that C++ code! With this tweak a longjmp over Rust code will no longer abort the process. A longjmp will continue to "accidentally" run Rust cleanups (destructors) on MSVC. Other non-MSVC platforms will not rust destructors with a longjmp, so we'll probably still recommend "don't have destructors on the stack", but in any case this is a more surgical fix than #48567 and should help us stick to standard personality functions a bit longer.
2018-02-27 03:59:47 +01:00
};
(Some(ret_llbb), Some(Funclet::new(cleanup)))
}).unzip()
}
/// Produce, for each argument, a `ValueRef` pointing at the
/// argument's value. As arguments are places, these are always
/// indirect.
2018-01-05 06:12:32 +01:00
fn arg_local_refs<'a, 'tcx>(bx: &Builder<'a, 'tcx>,
fx: &FunctionCx<'a, 'tcx>,
2016-12-18 03:54:32 +01:00
scopes: &IndexVec<mir::VisibilityScope, debuginfo::MirDebugScope>,
memory_locals: &BitVector)
2016-12-18 03:54:32 +01:00
-> Vec<LocalRef<'tcx>> {
let mir = fx.mir;
2018-01-05 06:12:32 +01:00
let tcx = bx.tcx();
let mut idx = 0;
let mut llarg_idx = fx.fn_ty.ret.is_indirect() as usize;
// Get the argument scope, if it exists and if we need it.
let arg_scope = scopes[mir::ARGUMENT_VISIBILITY_SCOPE];
2018-01-05 06:12:32 +01:00
let arg_scope = if arg_scope.is_valid() && bx.sess().opts.debuginfo == FullDebugInfo {
Some(arg_scope.scope_metadata)
} else {
None
};
let deref_op = unsafe {
[llvm::LLVMRustDIBuilderCreateOpDeref()]
};
mir.args_iter().enumerate().map(|(arg_index, local)| {
let arg_decl = &mir.local_decls[local];
2016-03-08 13:24:44 +01:00
let name = if let Some(name) = arg_decl.name {
name.as_str().to_string()
} else {
format!("arg{}", arg_index)
};
2016-09-27 02:03:35 +02:00
if Some(local) == mir.spread_arg {
// This argument (e.g. the last argument in the "rust-call" ABI)
// is a tuple that was spread at the ABI level and now we have
// to reconstruct it into a tuple local variable, from multiple
// individual LLVM function arguments.
let arg_ty = fx.monomorphize(&arg_decl.ty);
2016-09-27 02:03:35 +02:00
let tupled_arg_tys = match arg_ty.sty {
ty::TyTuple(ref tys) => tys,
2016-09-27 02:03:35 +02:00
_ => bug!("spread argument isn't a tuple?!")
};
2018-01-05 06:12:32 +01:00
let place = PlaceRef::alloca(bx, bx.cx.layout_of(arg_ty), &name);
for i in 0..tupled_arg_tys.len() {
let arg = &fx.fn_ty.args[idx];
2016-09-27 02:03:35 +02:00
idx += 1;
if arg.pad.is_some() {
llarg_idx += 1;
}
2018-01-05 06:12:32 +01:00
arg.store_fn_arg(bx, &mut llarg_idx, place.project_field(bx, i));
}
// Now that we have one alloca that contains the aggregate value,
// we can create one debuginfo entry for the argument.
2016-12-11 04:32:44 +01:00
arg_scope.map(|scope| {
let variable_access = VariableAccess::DirectVariable {
alloca: place.llval
};
declare_local(
2018-01-05 06:12:32 +01:00
bx,
&fx.debug_context,
arg_decl.name.unwrap_or(keywords::Invalid.name()),
arg_ty, scope,
variable_access,
VariableKind::ArgumentVariable(arg_index + 1),
DUMMY_SP
);
2016-12-11 04:32:44 +01:00
});
return LocalRef::Place(place);
2016-03-08 13:24:44 +01:00
}
let arg = &fx.fn_ty.args[idx];
idx += 1;
if arg.pad.is_some() {
llarg_idx += 1;
}
if arg_scope.is_none() && !memory_locals.contains(local.index()) {
// We don't have to cast or keep the argument in the alloca.
// FIXME(eddyb): We should figure out how to use llvm.dbg.value instead
// of putting everything in allocas just so we can use llvm.dbg.declare.
let local = |op| LocalRef::Operand(Some(op));
match arg.mode {
PassMode::Ignore => {
2018-01-05 06:12:32 +01:00
return local(OperandRef::new_zst(bx.cx, arg.layout));
}
PassMode::Direct(_) => {
2018-01-05 06:12:32 +01:00
let llarg = llvm::get_param(bx.llfn(), llarg_idx as c_uint);
bx.set_value_name(llarg, &name);
llarg_idx += 1;
return local(
2018-01-05 06:12:32 +01:00
OperandRef::from_immediate_or_packed_pair(bx, llarg, arg.layout));
}
PassMode::Pair(..) => {
2018-01-05 06:12:32 +01:00
let a = llvm::get_param(bx.llfn(), llarg_idx as c_uint);
bx.set_value_name(a, &(name.clone() + ".0"));
llarg_idx += 1;
2018-01-05 06:12:32 +01:00
let b = llvm::get_param(bx.llfn(), llarg_idx as c_uint);
bx.set_value_name(b, &(name + ".1"));
llarg_idx += 1;
return local(OperandRef {
val: OperandValue::Pair(a, b),
layout: arg.layout
});
}
_ => {}
}
}
let place = if arg.is_indirect() {
// Don't copy an indirect argument to an alloca, the caller
// already put it in a temporary alloca and gave it up.
// FIXME: lifetimes
2018-01-05 06:12:32 +01:00
let llarg = llvm::get_param(bx.llfn(), llarg_idx as c_uint);
bx.set_value_name(llarg, &name);
llarg_idx += 1;
PlaceRef::new_sized(llarg, arg.layout, arg.layout.align)
} else {
2018-01-05 06:12:32 +01:00
let tmp = PlaceRef::alloca(bx, arg.layout, &name);
arg.store_fn_arg(bx, &mut llarg_idx, tmp);
tmp
};
2016-12-11 04:32:44 +01:00
arg_scope.map(|scope| {
// Is this a regular argument?
if arg_index > 0 || mir.upvar_decls.is_empty() {
// The Rust ABI passes indirect variables using a pointer and a manual copy, so we
// need to insert a deref here, but the C ABI uses a pointer and a copy using the
// byval attribute, for which LLVM does the deref itself, so we must not add it.
// Starting with D31439 in LLVM 5, it *always* does the deref itself.
let mut variable_access = VariableAccess::DirectVariable {
alloca: place.llval
};
if unsafe { llvm::LLVMRustVersionMajor() < 5 } {
if let PassMode::Indirect(ref attrs) = arg.mode {
if !attrs.contains(ArgAttribute::ByVal) {
variable_access = VariableAccess::IndirectVariable {
alloca: place.llval,
address_operations: &deref_op,
};
}
}
}
declare_local(
2018-01-05 06:12:32 +01:00
bx,
&fx.debug_context,
arg_decl.name.unwrap_or(keywords::Invalid.name()),
arg.layout.ty,
scope,
variable_access,
VariableKind::ArgumentVariable(arg_index + 1),
DUMMY_SP
);
return;
}
// Or is it the closure environment?
let (closure_layout, env_ref) = match arg.layout.ty.sty {
ty::TyRawPtr(ty::TypeAndMut { ty, .. }) |
ty::TyRef(_, ty, _) => (bx.cx.layout_of(ty), true),
_ => (arg.layout, false)
};
2017-07-05 23:57:26 +02:00
let (def_id, upvar_substs) = match closure_layout.ty.sty {
ty::TyClosure(def_id, substs) => (def_id, UpvarSubsts::Closure(substs)),
ty::TyGenerator(def_id, substs, _) => (def_id, UpvarSubsts::Generator(substs)),
_ => bug!("upvar_decls with non-closure arg0 type `{}`", closure_layout.ty)
};
let upvar_tys = upvar_substs.upvar_tys(def_id, tcx);
// Store the pointer to closure data in an alloca for debuginfo
// because that's what the llvm.dbg.declare intrinsic expects.
// FIXME(eddyb) this shouldn't be necessary but SROA seems to
// mishandle DW_OP_plus not preceded by DW_OP_deref, i.e. it
// doesn't actually strip the offset when splitting the closure
// environment into its components so it ends up out of bounds.
let env_ptr = if !env_ref {
2018-01-05 06:12:32 +01:00
let scratch = PlaceRef::alloca(bx,
bx.cx.layout_of(tcx.mk_mut_ptr(arg.layout.ty)),
"__debuginfo_env_ptr");
2018-01-05 06:12:32 +01:00
bx.store(place.llval, scratch.llval, scratch.align);
scratch.llval
} else {
place.llval
};
for (i, (decl, ty)) in mir.upvar_decls.iter().zip(upvar_tys).enumerate() {
let byte_offset_of_var_in_env = closure_layout.fields.offset(i).bytes();
2016-12-20 03:14:27 +01:00
let ops = unsafe {
[llvm::LLVMRustDIBuilderCreateOpDeref(),
llvm::LLVMRustDIBuilderCreateOpPlusUconst(),
byte_offset_of_var_in_env as i64,
llvm::LLVMRustDIBuilderCreateOpDeref()]
};
// The environment and the capture can each be indirect.
// FIXME(eddyb) see above why we have to keep
// a pointer in an alloca for debuginfo atm.
let mut ops = if env_ref || true { &ops[..] } else { &ops[1..] };
let ty = if let (true, &ty::TyRef(_, ty, _)) = (decl.by_ref, &ty.sty) {
ty
} else {
ops = &ops[..ops.len() - 1];
ty
};
let variable_access = VariableAccess::IndirectVariable {
alloca: env_ptr,
address_operations: &ops
};
declare_local(
2018-01-05 06:12:32 +01:00
bx,
&fx.debug_context,
decl.debug_name,
ty,
scope,
variable_access,
VariableKind::CapturedVariable,
DUMMY_SP
);
}
2016-12-11 04:32:44 +01:00
});
LocalRef::Place(place)
}).collect()
}
mod analyze;
mod block;
mod constant;
pub mod place;
pub mod operand;
mod rvalue;
mod statement;