Page MenuHomeFreeBSD

Add further clarification on si_addr and si_trapno.
ClosedPublic

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

Details

Summary
  • In the initial description of si_addr, do not claim that it is always the faulting instruction.
  • For si_addr, document that it is generally set to the PC for synchronous signals, but that it can be set to the the address of the faulting memory reference including SIGSEGV and SIGBUS. In particular, while SIGSEGV generally sets si_addr to the faulting memory reference, SIGBUS can vary. On some platforms, some SIGBUS signals set si_addr to the PC and other SIGBUS signals set si_addr to the faulting address depending on the specific hardware exception.
  • For si_trapno, synchronous signals should set this to some value.

Diff Detail

Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 32581
Build 30037: arc lint + arc unit

Event Timeline

jhb requested review of this revision.Jul 22 2020, 4:36 PM
jhb created this revision.
share/man/man3/siginfo.3
223

I am confused by your terminology there. Synchronous signals are always sent due to an instruction action, even it the instruction generated a trap/fault that was caused by invalid memory access.

After some re-reading, I think you are trying to state that if there was a memory access to specific address that faulted, the address is reported in si_addr, otherwise the address of faulting instruction is reported in si_addr. Even this is not completely true, and you are right that you used 'may' when described that SIGSEGV/SIGBUS may report the faulting address, but could not (e.g. on x86 page faults do, but segmentation faults do not).

I believe I was confused by 'in response to an instruction' part.

share/man/man3/siginfo.3
223

I'm trying to distinguish from async signals sent via kill(2), etc. However, perhaps synchronous already covers this and I can just drop the problematic "in response to an instruction".

I did use "may" to mean "you have to read the trap handler for the arch in question to determine what you get".

Curiously, the POSIX (open group) description of si_addr says that SIGSEGV/SIGBUS always report a faulting memory reference: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html

share/man/man3/siginfo.3
223

I always interpreted 'synchronous signals' as system reaction to traps. I.e., in our terms, results of trapsignal().

Indeed, we are not compliant with POSIX for SIGSEGV/SIGBUS, but it really reduces to two cases: 1. For non-canonical addresses and SIGSEGV, we indeed do not report the faulting address, because hardware does not provide the value. 2. For segmentation faults, the faulting address is not representable in the uintptr_t.

share/man/man3/siginfo.3
214

typo missed 'n' in syNchronous

220

it reads as 'if si_addr is available'.

Might be, 'if hardware provides it'.

222

still 'in response to an instruction' is confusing. Either mark that as explanation, i.e. Synchronous signals, i.e. signals raised in response to faulting instruction. Or remove that part at all.

Doesn't we always set si_trapno, after you commits ?

jhb marked 2 inline comments as done.Jul 27 2020, 7:41 PM
jhb added inline comments.
share/man/man3/siginfo.3
220

I moved the "if available" earlier to try to make it less ambiguous.

222

Oh, yes, just failed to fix both places.

Hmm, I guess we do always set si_trapno now.

jhb marked an inline comment as done.
  • More wording tweaks.
This revision is now accepted and ready to land.Jul 27 2020, 8:36 PM
This revision was automatically updated to reflect the committed changes.