Page MenuHomeFreeBSD

Set si_trapno to the exception code from esr.

Authored by jhb on Jul 22 2020, 4:30 PM.


Diff Detail

rS FreeBSD src repository - subversion
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; 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.