Date: Fri, 15 Feb 2019 21:54:39 +0100 From: Christian Barthel <bch@online.de> To: John Baldwin <jhb@FreeBSD.org> Cc: freebsd-chat@freebsd.org Subject: Re: siginfo_t content Message-ID: <87wom0lqls.fsf@x230.onfire.org> In-Reply-To: <19b54bd0-7e1c-67f2-089b-87350455b3bd@FreeBSD.org> (John Baldwin's message of "Fri, 15 Feb 2019 10:12:01 -0800") References: <875ztmitqw.fsf@x230.onfire.org> <12fe52ea-1ab7-58b0-26d2-2c393570dd2f@FreeBSD.org> <87sgwpovdf.fsf@x230.onfire.org> <19b54bd0-7e1c-67f2-089b-87350455b3bd@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin <jhb@FreeBSD.org> writes: > 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? I've read about profilers at [0] and thought about how to implementing one myself. My initial idea was to setitimer() and keep track of the PC with SIGPROF and calculate "hot regions". Then, I started wondering myself why/how the SIGPROF is meant to be used, since the current program counter was the first thing that came to my mind when thinking about profiling. But I guess, I have to keep track of the current function (or even the stack trace myself and use it within the signal handler to determine hot paths and regions). I know about gprof and DTrace but I am more interested in how to do it on my own and see, how far I can go. [0] https://research.swtch.com/pprof -- Christian Barthel <bch@online.de>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87wom0lqls.fsf>