Date: Fri, 15 Feb 2019 10:12:01 -0800 From: John Baldwin <jhb@FreeBSD.org> To: Christian Barthel <bch@online.de> Cc: freebsd-chat@freebsd.org Subject: Re: siginfo_t content Message-ID: <19b54bd0-7e1c-67f2-089b-87350455b3bd@FreeBSD.org> In-Reply-To: <87sgwpovdf.fsf@x230.onfire.org> References: <875ztmitqw.fsf@x230.onfire.org> <12fe52ea-1ab7-58b0-26d2-2c393570dd2f@FreeBSD.org> <87sgwpovdf.fsf@x230.onfire.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2/15/19 8:43 AM, Christian Barthel wrote: > John Baldwin <jhb@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19b54bd0-7e1c-67f2-089b-87350455b3bd>