Page MenuHomeFreeBSD

Add further clarification on si_addr and si_trapno.

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


  • 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 OK
No Unit Test Coverage
Build Status
Buildable 32586
Build 30042: arc lint + arc unit

Event Timeline

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

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.


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:


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.


typo missed 'n' in syNchronous


it reads as 'if si_addr is available'.

Might be, 'if hardware provides it'.


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.

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


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.