[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANiq72nv8CK8cyY4n3yqpL6GAmqmVP5+Ee-cgzT9Gi+ZRLE_Jw@mail.gmail.com>
Date: Fri, 16 Apr 2021 19:34:51 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Miguel Ojeda <ojeda@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
rust-for-linux@...r.kernel.org,
Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
Linux Doc Mailing List <linux-doc@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Alex Gaynor <alex.gaynor@...il.com>,
Geoffrey Thomas <geofft@...reload.com>,
Finn Behrens <me@...enk.de>,
Adam Bratschi-Kaye <ark.email@...il.com>,
Wedson Almeida Filho <wedsonaf@...gle.com>,
Michael Ellerman <mpe@...erman.id.au>
Subject: Re: [PATCH 04/13] Kbuild: Rust support
On Fri, Apr 16, 2021 at 3:38 PM Peter Zijlstra <peterz@...radead.org> 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
Powered by blists - more mailing lists