]> git.lizzy.rs Git - rust.git/blob - src/libpanic_unwind/seh.rs
Rollup merge of #68438 - Aaron1011:fix/tait-non-defining, r=estebank
[rust.git] / src / libpanic_unwind / seh.rs
1 //! Windows SEH
2 //!
3 //! On Windows (currently only on MSVC), the default exception handling
4 //! mechanism is Structured Exception Handling (SEH). This is quite different
5 //! than Dwarf-based exception handling (e.g., what other unix platforms use) in
6 //! terms of compiler internals, so LLVM is required to have a good deal of
7 //! extra support for SEH.
8 //!
9 //! In a nutshell, what happens here is:
10 //!
11 //! 1. The `panic` function calls the standard Windows function
12 //!    `_CxxThrowException` to throw a C++-like exception, triggering the
13 //!    unwinding process.
14 //! 2. All landing pads generated by the compiler use the personality function
15 //!    `__CxxFrameHandler3`, a function in the CRT, and the unwinding code in
16 //!    Windows will use this personality function to execute all cleanup code on
17 //!    the stack.
18 //! 3. All compiler-generated calls to `invoke` have a landing pad set as a
19 //!    `cleanuppad` LLVM instruction, which indicates the start of the cleanup
20 //!    routine. The personality (in step 2, defined in the CRT) is responsible
21 //!    for running the cleanup routines.
22 //! 4. Eventually the "catch" code in the `try` intrinsic (generated by the
23 //!    compiler) is executed and indicates that control should come back to
24 //!    Rust. This is done via a `catchswitch` plus a `catchpad` instruction in
25 //!    LLVM IR terms, finally returning normal control to the program with a
26 //!    `catchret` instruction.
27 //!
28 //! Some specific differences from the gcc-based exception handling are:
29 //!
30 //! * Rust has no custom personality function, it is instead *always*
31 //!   `__CxxFrameHandler3`. Additionally, no extra filtering is performed, so we
32 //!   end up catching any C++ exceptions that happen to look like the kind we're
33 //!   throwing. Note that throwing an exception into Rust is undefined behavior
34 //!   anyway, so this should be fine.
35 //! * We've got some data to transmit across the unwinding boundary,
36 //!   specifically a `Box<dyn Any + Send>`. Like with Dwarf exceptions
37 //!   these two pointers are stored as a payload in the exception itself. On
38 //!   MSVC, however, there's no need for an extra heap allocation because the
39 //!   call stack is preserved while filter functions are being executed. This
40 //!   means that the pointers are passed directly to `_CxxThrowException` which
41 //!   are then recovered in the filter function to be written to the stack frame
42 //!   of the `try` intrinsic.
43 //!
44 //! [win64]: https://docs.microsoft.com/en-us/cpp/build/exception-handling-x64
45 //! [llvm]: http://llvm.org/docs/ExceptionHandling.html#background-on-windows-exceptions
46
47 #![allow(nonstandard_style)]
48 #![allow(private_no_mangle_fns)]
49
50 use alloc::boxed::Box;
51 use core::any::Any;
52 use core::mem;
53 use core::raw;
54 use libc::{c_int, c_uint, c_void};
55
56 // First up, a whole bunch of type definitions. There's a few platform-specific
57 // oddities here, and a lot that's just blatantly copied from LLVM. The purpose
58 // of all this is to implement the `panic` function below through a call to
59 // `_CxxThrowException`.
60 //
61 // This function takes two arguments. The first is a pointer to the data we're
62 // passing in, which in this case is our trait object. Pretty easy to find! The
63 // next, however, is more complicated. This is a pointer to a `_ThrowInfo`
64 // structure, and it generally is just intended to just describe the exception
65 // being thrown.
66 //
67 // Currently the definition of this type [1] is a little hairy, and the main
68 // oddity (and difference from the online article) is that on 32-bit the
69 // pointers are pointers but on 64-bit the pointers are expressed as 32-bit
70 // offsets from the `__ImageBase` symbol. The `ptr_t` and `ptr!` macro in the
71 // modules below are used to express this.
72 //
73 // The maze of type definitions also closely follows what LLVM emits for this
74 // sort of operation. For example, if you compile this C++ code on MSVC and emit
75 // the LLVM IR:
76 //
77 //      #include <stdint.h>
78 //
79 //      struct rust_panic {
80 //          rust_panic(const rust_panic&);
81 //          ~rust_panic();
82 //
83 //          uint64_t x[2];
84 //      };
85 //
86 //      void foo() {
87 //          rust_panic a = {0, 1};
88 //          throw a;
89 //      }
90 //
91 // That's essentially what we're trying to emulate. Most of the constant values
92 // below were just copied from LLVM,
93 //
94 // In any case, these structures are all constructed in a similar manner, and
95 // it's just somewhat verbose for us.
96 //
97 // [1]: http://www.geoffchappell.com/studies/msvc/language/predefined/
98
99 #[cfg(target_arch = "x86")]
100 #[macro_use]
101 mod imp {
102     pub type ptr_t = *mut u8;
103
104     macro_rules! ptr {
105         (0) => {
106             core::ptr::null_mut()
107         };
108         ($e:expr) => {
109             $e as *mut u8
110         };
111     }
112 }
113
114 #[cfg(any(target_arch = "x86_64", target_arch = "arm"))]
115 #[macro_use]
116 mod imp {
117     pub type ptr_t = u32;
118
119     extern "C" {
120         pub static __ImageBase: u8;
121     }
122
123     macro_rules! ptr {
124         (0) => (0);
125         ($e:expr) => {
126             (($e as usize) - (&imp::__ImageBase as *const _ as usize)) as u32
127         }
128     }
129 }
130
131 #[repr(C)]
132 pub struct _ThrowInfo {
133     pub attributes: c_uint,
134     pub pmfnUnwind: imp::ptr_t,
135     pub pForwardCompat: imp::ptr_t,
136     pub pCatchableTypeArray: imp::ptr_t,
137 }
138
139 #[repr(C)]
140 pub struct _CatchableTypeArray {
141     pub nCatchableTypes: c_int,
142     pub arrayOfCatchableTypes: [imp::ptr_t; 1],
143 }
144
145 #[repr(C)]
146 pub struct _CatchableType {
147     pub properties: c_uint,
148     pub pType: imp::ptr_t,
149     pub thisDisplacement: _PMD,
150     pub sizeOrOffset: c_int,
151     pub copyFunction: imp::ptr_t,
152 }
153
154 #[repr(C)]
155 pub struct _PMD {
156     pub mdisp: c_int,
157     pub pdisp: c_int,
158     pub vdisp: c_int,
159 }
160
161 #[repr(C)]
162 pub struct _TypeDescriptor {
163     pub pVFTable: *const u8,
164     pub spare: *mut u8,
165     pub name: [u8; 11],
166 }
167
168 // Note that we intentionally ignore name mangling rules here: we don't want C++
169 // to be able to catch Rust panics by simply declaring a `struct rust_panic`.
170 const TYPE_NAME: [u8; 11] = *b"rust_panic\0";
171
172 static mut THROW_INFO: _ThrowInfo = _ThrowInfo {
173     attributes: 0,
174     pmfnUnwind: ptr!(0),
175     pForwardCompat: ptr!(0),
176     pCatchableTypeArray: ptr!(0),
177 };
178
179 static mut CATCHABLE_TYPE_ARRAY: _CatchableTypeArray =
180     _CatchableTypeArray { nCatchableTypes: 1, arrayOfCatchableTypes: [ptr!(0)] };
181
182 static mut CATCHABLE_TYPE: _CatchableType = _CatchableType {
183     properties: 0,
184     pType: ptr!(0),
185     thisDisplacement: _PMD { mdisp: 0, pdisp: -1, vdisp: 0 },
186     sizeOrOffset: mem::size_of::<[u64; 2]>() as c_int,
187     copyFunction: ptr!(0),
188 };
189
190 extern "C" {
191     // The leading `\x01` byte here is actually a magical signal to LLVM to
192     // *not* apply any other mangling like prefixing with a `_` character.
193     //
194     // This symbol is the vtable used by C++'s `std::type_info`. Objects of type
195     // `std::type_info`, type descriptors, have a pointer to this table. Type
196     // descriptors are referenced by the C++ EH structures defined above and
197     // that we construct below.
198     #[link_name = "\x01??_7type_info@@6B@"]
199     static TYPE_INFO_VTABLE: *const u8;
200 }
201
202 // We use #[lang = "eh_catch_typeinfo"] here as this is the type descriptor which
203 // we'll use in LLVM's `catchpad` instruction which ends up also being passed as
204 // an argument to the C++ personality function.
205 //
206 // Again, I'm not entirely sure what this is describing, it just seems to work.
207 #[cfg_attr(not(test), lang = "eh_catch_typeinfo")]
208 static mut TYPE_DESCRIPTOR: _TypeDescriptor = _TypeDescriptor {
209     pVFTable: unsafe { &TYPE_INFO_VTABLE } as *const _ as *const _,
210     spare: core::ptr::null_mut(),
211     name: TYPE_NAME,
212 };
213
214 // Destructor used if the C++ code decides to capture the exception and drop it
215 // without propagating it. The catch part of the try intrinsic will set the
216 // first word of the exception object to 0 so that it is skipped by the
217 // destructor.
218 //
219 // Note that x86 Windows uses the "thiscall" calling convention for C++ member
220 // functions instead of the default "C" calling convention.
221 //
222 // The exception_copy function is a bit special here: it is invoked by the MSVC
223 // runtime under a try/catch block and the panic that we generate here will be
224 // used as the result of the exception copy. This is used by the C++ runtime to
225 // support capturing exceptions with std::exception_ptr, which we can't support
226 // because Box<dyn Any> isn't clonable.
227 macro_rules! define_cleanup {
228     ($abi:tt) => {
229         unsafe extern $abi fn exception_cleanup(e: *mut [u64; 2]) {
230             if (*e)[0] != 0 {
231                 cleanup(*e);
232                 super::__rust_drop_panic();
233             }
234         }
235         #[unwind(allowed)]
236         unsafe extern $abi fn exception_copy(_dest: *mut [u64; 2],
237                                              _src: *mut [u64; 2])
238                                              -> *mut [u64; 2] {
239             panic!("Rust panics cannot be copied");
240         }
241     }
242 }
243 cfg_if::cfg_if! {
244    if #[cfg(target_arch = "x86")] {
245        define_cleanup!("thiscall");
246    } else {
247        define_cleanup!("C");
248    }
249 }
250
251 pub unsafe fn panic(data: Box<dyn Any + Send>) -> u32 {
252     use core::intrinsics::atomic_store;
253
254     // _CxxThrowException executes entirely on this stack frame, so there's no
255     // need to otherwise transfer `data` to the heap. We just pass a stack
256     // pointer to this function.
257     //
258     // The first argument is the payload being thrown (our two pointers), and
259     // the second argument is the type information object describing the
260     // exception (constructed above).
261     let ptrs = mem::transmute::<_, raw::TraitObject>(data);
262     let mut ptrs = [ptrs.data as u64, ptrs.vtable as u64];
263     let throw_ptr = ptrs.as_mut_ptr() as *mut _;
264
265     // This... may seems surprising, and justifiably so. On 32-bit MSVC the
266     // pointers between these structure are just that, pointers. On 64-bit MSVC,
267     // however, the pointers between structures are rather expressed as 32-bit
268     // offsets from `__ImageBase`.
269     //
270     // Consequently, on 32-bit MSVC we can declare all these pointers in the
271     // `static`s above. On 64-bit MSVC, we would have to express subtraction of
272     // pointers in statics, which Rust does not currently allow, so we can't
273     // actually do that.
274     //
275     // The next best thing, then is to fill in these structures at runtime
276     // (panicking is already the "slow path" anyway). So here we reinterpret all
277     // of these pointer fields as 32-bit integers and then store the
278     // relevant value into it (atomically, as concurrent panics may be
279     // happening). Technically the runtime will probably do a nonatomic read of
280     // these fields, but in theory they never read the *wrong* value so it
281     // shouldn't be too bad...
282     //
283     // In any case, we basically need to do something like this until we can
284     // express more operations in statics (and we may never be able to).
285     if !cfg!(bootstrap) {
286         atomic_store(
287             &mut THROW_INFO.pmfnUnwind as *mut _ as *mut u32,
288             ptr!(exception_cleanup) as u32,
289         );
290     }
291     atomic_store(
292         &mut THROW_INFO.pCatchableTypeArray as *mut _ as *mut u32,
293         ptr!(&CATCHABLE_TYPE_ARRAY as *const _) as u32,
294     );
295     atomic_store(
296         &mut CATCHABLE_TYPE_ARRAY.arrayOfCatchableTypes[0] as *mut _ as *mut u32,
297         ptr!(&CATCHABLE_TYPE as *const _) as u32,
298     );
299     atomic_store(
300         &mut CATCHABLE_TYPE.pType as *mut _ as *mut u32,
301         ptr!(&TYPE_DESCRIPTOR as *const _) as u32,
302     );
303     if !cfg!(bootstrap) {
304         atomic_store(
305             &mut CATCHABLE_TYPE.copyFunction as *mut _ as *mut u32,
306             ptr!(exception_copy) as u32,
307         );
308     }
309
310     extern "system" {
311         #[unwind(allowed)]
312         pub fn _CxxThrowException(pExceptionObject: *mut c_void, pThrowInfo: *mut u8) -> !;
313     }
314
315     _CxxThrowException(throw_ptr, &mut THROW_INFO as *mut _ as *mut _);
316 }
317
318 pub fn payload() -> [u64; 2] {
319     [0; 2]
320 }
321
322 pub unsafe fn cleanup(payload: [u64; 2]) -> Box<dyn Any + Send> {
323     mem::transmute(raw::TraitObject { data: payload[0] as *mut _, vtable: payload[1] as *mut _ })
324 }
325
326 // This is required by the compiler to exist (e.g., it's a lang item), but
327 // it's never actually called by the compiler because __C_specific_handler
328 // or _except_handler3 is the personality function that is always used.
329 // Hence this is just an aborting stub.
330 #[lang = "eh_personality"]
331 #[cfg(not(test))]
332 fn rust_eh_personality() {
333     unsafe { core::intrinsics::abort() }
334 }