Page MenuHomeFreeBSD

Set si_trapno to the exception code from esr.
ClosedPublic

Authored by jhb on Jul 22 2020, 4:30 PM.
Tags
None
Referenced Files
Unknown Object (File)
Oct 22 2024, 6:05 PM
Unknown Object (File)
Oct 4 2024, 8:33 PM
Unknown Object (File)
Oct 1 2024, 6:05 PM
Unknown Object (File)
Sep 20 2024, 6:13 PM
Unknown Object (File)
Sep 10 2024, 2:42 AM
Unknown Object (File)
Sep 8 2024, 7:38 PM
Unknown Object (File)
Sep 8 2024, 2:42 PM
Unknown Object (File)
Sep 6 2024, 3:40 AM
Subscribers

Details

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

jhb requested review of this revision.Jul 22 2020, 4:30 PM

May be, just copy the esr value as is. There is additional encoding of trap cause in ISS field.

On the other hand, tf_esr is available through the ucontext, when ucontext is available, i.e. in the handler.

What I tried to do in this series is pick the "fault number" portion of the relevant register (since it is "trap number"). E.g. on RISC-V it excludes the bit in scause that is for interrupts, though in practice that means scause == si_trapno since the bit is 0 for exceptions. If it was si_cause or some such I would perhaps put the whole register value. OTOH, si_trapno isn't in POSIX, so we can define it to whatever we want. It's not clear to me that the mcontext_t always contains the relevant register on all platforms. (One other thing I haven't tried to fix is to put the constants for the values in si_trapno in <machine/trap.h>. riscv puts them in <machine/riscvreg.h> instead, and I suspect aarch64 is similarly broken since riscv is a copy-paste of aarch64)

I guess all that to say, I don't have a strong preference either way on what we put in si_trapno except that I'd like us to be consistent, and either always include the full contents of the relevant register, or always only include a trap "number".

When I wrote a response yesterday, my motivation was that it is important to provide as much information as we can for the trap signal cause. But, as an after-thought, I realized that siginfo_t is not useful for this purpose, it drops a lot of very important data from the faulting context. In other words, either code has access to ucontext for the fault, or it does not matter much which data we loose. From this point of view, providing just the trap number (for some definition of it) is good enough.

This revision is now accepted and ready to land.Jul 23 2020, 9:05 PM
This revision was automatically updated to reflect the committed changes.