siginfo_t content
Christian Barthel
bch at online.de
Fri Feb 15 20:54:50 UTC 2019
John Baldwin <jhb at FreeBSD.org> writes:
> On 2/15/19 8:43 AM, Christian Barthel wrote:
>> John Baldwin <jhb at 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 at online.de>
More information about the freebsd-chat
mailing list