-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Arm32 EABI exception handling #128156
Comments
## NetBSD
According to this [lovingly detailed commit
message](32f9b53),
NetBSD on 32-bit Arm using the EABI does not use the Arm EABI
exception handling routines.
However, perhaps because it was not seen as relevant, it was
not documented what it does use as its approach for
unwinding. This is unfortunate, as we have recently seen Arm
bugs on NetBSD that appear to be caused by assuming NetBSD on
Arm must operate exactly like it does on x86, and discovering
we are wrong, because of bugs or other reasons.
@he32 Do all NetBSD architectures use the same unwinding? Do we
even unwind correctly on the not-so-x86 NetBSD architectures?
Apparently not if this is to be believed?
#96914
You ask good questions for putting me on the spot. :)
I cannot claim to comprehend the first commit above and its
implications.
My attempt along these lines are perhaps somewhat cargo-cult
driven, and
https://mail-index.netbsd.org/pkgsrc-changes/2022/05/18/msg254732.html
was my best attempt at providing rust with backtrace() and
associated functions, and the intention from my side was that all
the NetBSD ports should link with -lexecinfo and get the support
for doing this from that library. Some if not most of these
changes have also been upstreamed.
However, what I have never found documentation for is "this is
how you interface the rust compiler to your OS / platform", it's
apparent that that's supposed to be self-evident from the code,
which makes following along quite the struggle.
At least the original PR appears to be fixed for amd64:
```
$ uname -rp
10.0_RC3 x86_64
$ rustc --version
rustc 1.73.0 (cc66ad4 2023-10-03)
$ cat t.rs
fn main() { panic!("explode!") }
$ rustc t.rs
$ ./t
thread 'main' panicked at t.rs:1:13:
explode!
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
$ env RUST_BACKTRACE=1 ./t
thread 'main' panicked at t.rs:1:13:
explode!
stack backtrace:
0: std::panicking::begin_panic
1: t::main
2: core::ops::function::FnOnce::call_once
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
$
```
However, my arm systems are out of reach at the moment, will
regain access over the weekend.
And ... I've also lately had problems getting rust to work at all
on the 32-bit arm systems since about rust 1.77.1.
I used to be able to self-host rust on 32-bit armv6 and armv7,
but not so anymore. I tend to put some distrust in "cross
compiling is a thing" as sufficient for adequate
stress-testing...
|
Yes! I do happen to ask incisive questions, and thank you for answering them! Even when you give an "I don't know", that is quite a lot better than having no idea whatsoever. At least then we know it is an unknown, and might cost effort to find an answer. Fortunately I also have almost no such belief that things should be "self-evident from the code", especially when it is a matter of a complicated system interface. You will notice that I try to add documentation for later reference as I go: workingjubilee@fcf7539 |
Ooh, things get even more exciting soon! #130077 |
I am opening this issue to track work regarding improving Arm 32-bit EABI exception-handling. There are a few fixmes that were never addressed and some things that I found a bit unclear. These are currently mostly questions, and it is possible this issue may be resolved fully by merely answering the questions (and hopefully committing an answer somewhere).
Arm, GCC, exceptions, and r12
We find this comment in our source:
rust/library/std/src/sys/personality/gcc.rs
Lines 126 to 136 in 6106b05
It's unclear what benefits this has, to me, and if our codegen backend could even exploit them, theoretically, if we did this. Mere correctness? Perhaps mere correctness is worth it, it might just be a fairly simple def.
NetBSD
According to this lovingly detailed commit message, NetBSD on 32-bit Arm using the EABI does not use the Arm EABI exception handling routines.
However, perhaps because it was not seen as relevant, it was not documented what it does use as its approach for unwinding. This is unfortunate, as we have recently seen Arm bugs on NetBSD that appear to be caused by assuming NetBSD on Arm must operate exactly like it does on x86, and discovering we are wrong, because of bugs or other reasons.
@he32 Do all NetBSD architectures use the same unwinding? Do we even unwind correctly on the not-so-x86 NetBSD architectures? Apparently not if this is to be believed? #96914
The text was updated successfully, but these errors were encountered: