File: sepcomp-unwind.rs

package info (click to toggle)
rustc 1.85.0%2Bdfsg3-1
  • links: PTS, VCS
  • area: main
  • in suites: experimental, sid, trixie
  • size: 893,396 kB
  • sloc: xml: 158,127; python: 35,830; javascript: 19,497; cpp: 19,002; sh: 17,245; ansic: 13,127; asm: 4,376; makefile: 1,051; perl: 29; lisp: 29; ruby: 19; sql: 11
file content (35 lines) | stat: -rw-r--r-- 813 bytes parent folder | download | duplicates (4)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
//@ run-pass
//@ needs-unwind
#![allow(dead_code)]
//@ compile-flags: -C codegen-units=3
//@ ignore-emscripten no threads support

// Test unwinding through multiple compilation units.

// According to acrichto, in the distant past `ld -r` (which is used during
// linking when codegen-units > 1) was known to produce object files with
// damaged unwinding tables.  This may be related to GNU binutils bug #6893
// ("Partial linking results in corrupt .eh_frame_hdr"), but I'm not certain.
// In any case, this test should let us know if enabling parallel codegen ever
// breaks unwinding.


use std::thread;

fn pad() -> usize { 0 }

mod a {
    pub fn f() {
        panic!();
    }
}

mod b {
    pub fn g() {
        ::a::f();
    }
}

fn main() {
    thread::spawn(move|| { ::b::g() }).join().unwrap_err();
}