Re: Accessing ESR from signal handlers on AArch64
Warner Losh <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.hackers |
|---|---|
| Message-ID | <CANCZdfpLSEO0_qaK7cmA_Fc1WKoP6b2E8Frkdg73YbAwXakH+g@mail.gmail.com> |
On Sat, Feb 28, 2026 at 1:07 PM Alex Arslan <[email protected]> wrote: > > > > On Feb 27, 2026, at 10:00 AM, Adrian Chadd <[email protected]> wrote: > > > > (fwiw, i recommend "silence" as a response being "noone's doing it, > > please go do it and ask questions" :-) ) > > Noted, thank you! I've opened a pull request on GitHub with the described > changes: https://github.com/freebsd/freebsd-src/pull/2053. If it would be > more conducive to review/discussion to have that in Phabricator rather than > GitHub, I can close that pull request and resubmit to Phabricator, though > it seems Andrew Turner was already auto-pinged for review on GitHub. > GitHub is fine. This change is well suited to github: It looks good to go, it looks like we're binary compatible, it's small and easy to digest, and the reviewer is active enough on github. Bonus points if this worked in the linuxulator and bsd-user though :). Warner > > -a > > > > On Wed, 25 Feb 2026 at 12:09, Alex Arslan <[email protected]> wrote: > >> > >> Hello, > >> > >> Currently there's no way to access the exception syndrome register (ESR) > >> on AArch64 from a signal handler. Nearly 10 years ago, this was > "expected > >> to be fixed soon"[1]; is that still on anybody's radar? In 2019, a patch > >> was submitted by a contributor to expose ESR via `mcontext_t`[2], but > that > >> has had no comments to date. I reached out to the author and it sounds > >> like she isn't planning to push on that revision. I would be happy to > help > >> make this happen, but I would need some handholding, and I don't want to > >> duplicate effort if somebody else is already planning to take it on. > >> > >> From what I understand, the way to go about this would be to: > >> > >> - Update `struct __mcontext` to include a new `__register_t` field > `mc_esr` > >> - Reduce the size of `mc_spare` by 1 to account for the addition > >> - Put `mc_esr` between `mc_ptr` and `mc_spare` to avoid affecting the > ABI > >> - Define a new bitmask `_MC_ESR_VALID` to set for `mc_flags`, analogous > to > >> the existing `_MC_FP_VALID` for `mc_fpregs` > >> - In `sendsig`, populate the `struct trapframe` field `tf_esr` with the > >> register value using `READ_SPECIALREG(esr_el1)` > >> - In `get_mcontext`, set `mc_esr` to `tf_esr` and update `mc_flags` > >> - In `set_mcontext`, set `tf_esr` to `mc_esr` if indicated by `mc_flags` > >> > >> Is that correct? Are there any steps or changes there that are missing? > >> > >> I'm not clear on whether it's appropriate to do so in the FreeBSD source > >> tree or if it should first go into upstream LLVM, but the compiler-rt > >> sanitizers could be updated to grab `mc_esr` via `ucontext_t` on FreeBSD > >> so that write vs. read faults may be differentiated. > >> > >> The Julia programming language performs a similar query to the > sanitizers, > >> checking ESR on AArch64 to determine whether a `SIGSEGV` occurred due to > >> a bad write and generating an appropriate runtime exception. On FreeBSD > >> AArch64, we can't determine this, so we end up in the state of "well, > there > >> was a segfault and we haven't otherwise handled it, so RIP your > process." > >> (Addressing this is my motivation for pursuing the change described > here.) > >> > >> Thanks! > >> > >> [1]: https://reviews.llvm.org/D32172 > >> [2]: https://reviews.freebsd.org/D20838 > > >