On Fri, Apr 16, 2021 at 3:38 PM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > So if I read all this right, rust compiles to .o and, like any other .o > file is then fed into objtool (for x86_64). Did you have any problems > with objtool? Does it generate correct ORC unwind information? I opened an issue a while ago to take a closer look at the ORC unwinder etc., so it is in my radar (thanks for raising it up, nevertheless!). Currently, causing a panic in a nested non-inlined function (f -> g -> h) in one of the samples with the ORC unwinder enabled gives me something like: [ 0.903456] rust_begin_unwind+0x9/0x10 [ 0.903456] ? _RNvNtCsbDqzXfLQacH_4core9panicking9panic_fmt+0x29/0x30 [ 0.903456] ? _RNvNtCsbDqzXfLQacH_4core9panicking5panic+0x44/0x50 [ 0.903456] ? _RNvCsbDqzXfLQacH_12rust_minimal1h+0x1c/0x20 [ 0.903456] ? _RNvCsbDqzXfLQacH_12rust_minimal1g+0x9/0x10 [ 0.903456] ? _RNvCsbDqzXfLQacH_12rust_minimal1f+0x9/0x10 [ 0.903456] ? _RNvXCsbDqzXfLQacH_12rust_minimalNtB2_11RustMinimalNtCsbDqzXfLQacH_6kernel12KernelModule4init+0x73/0x80 [ 0.903456] ? _RNvXsa_NtCsbDqzXfLQacH_4core3fmtbNtB5_5Debug3fmt+0x30/0x30 [ 0.903456] ? __rust_minimal_init+0x11/0x20 But it also shows this one below: [ 0.903456] ? _RNvXs5_NtCsbDqzXfLQacH_11rust_binder11range_allocNtB5_15DescriptorStateNtNtCsbDqzXfLQacH_4core3fmt5Debug3fmt+0x60/0x60 So something does not look correct. > AFAICT rust has try/throw/catch exception handling (like > C++/Java/others) which is typically implemented with stack unwinding of > its own. Rust has optional unwinding for panics, yeah, but we don't enable it. Instead, we tell the compiler to use its "abort" panic strategy. In the handler currently we just call `BUG()`, but we will need to do something less aggressive (e.g. kill the current thread). But please note that it is not our plan to rely on panics for normal error conditions. For instance, the allocations currently panic due to our re-use of `alloc`, but will be fallible eventually (`Result` etc.). Cheers, Miguel
