On 2/15/19 8:43 AM, Christian Barthel wrote: > John Baldwin <j...@freebsd.org> writes: > >> See the siginfo(3) manpage. SI_TIMER is described there as: >> >> SI_TIMER signal generated by expiration of a >> timer set by timer_settime(2) >> >> It is not for setitimer. Similarly, si_addr is usually only specified for >> synchronous signals and usually holds the PC of the faulting instruction >> except for SIGSEGV when it holds the faulting virtual address. > > Thanks for your reply. > Ah, yes, siginfo(3) has more details on siginfo_t (missed that > one; sorry). This clarifies my question. > I've looked up the POSIX standard but I haven't seen a reason why > si_addr is only set for SIGSEGV and "only" a few others - are > there reasons for this?
I think it's only intended for use with synchronous traps where the signal is the result of executing an instruction (so si_addr is usually the PC of the instruction triggering the signal). Async events like timers aren't triggered by instructions, so there's no meaningful si_addr to use. However, in a signal handler you can look at the architecture-specific ucontext_t * (3rd argument to handler when using SA_SIGINFO) to determine the PC of the thread at the time it was interrupted by the signal. What are you trying to do exactly? -- John Baldwin _______________________________________________ freebsd-chat@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-chat To unsubscribe, send any mail to "freebsd-chat-unsubscr...@freebsd.org"