Date: Thu, 14 Feb 2019 12:20:45 -0800 From: John Baldwin <jhb@FreeBSD.org> To: Christian Barthel <bch@online.de>, freebsd-chat@freebsd.org Subject: Re: siginfo_t content Message-ID: <12fe52ea-1ab7-58b0-26d2-2c393570dd2f@FreeBSD.org> In-Reply-To: <875ztmitqw.fsf@x230.onfire.org> References: <875ztmitqw.fsf@x230.onfire.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2/14/19 1:50 AM, Christian Barthel wrote:
> Hello,
> I am interested in the historical development of the siginfo_t
> record. I hope, this is the correct mailinglist and there are
> still readers on it.
>
> I've tried to write a very simple and minimalistic profiler for a
> single threaded application by using setitimer(2) and SIGPROF
> signal. When using the extended signal handler code described in
> the EXAMPLES section of sigaction(2), I can access the faulting
> code and the type of the signal by using `struct siginfo`:
>
> File: <sys/signal.h>
> struct siginfo_t *info {
> ....
> int si_code; /* signal code */
> void *si_addr; /* faulting instruction */
> ....
> }
>
> I've noticed that the si_code is always set to be SI_KERNEL and
> the si_addr to be 0x0. Is there a specific reason for this?
>
> I thought that the SIGPROF signal would be of type SI_TIMER.
> After reading through the kernel sources, I've manipulated the
> returned structure a bit and attached the patch to clarify what I
> am meaning (I've just used the program counter of the first
> thread which is not correct if there are multiple threads).
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.
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?12fe52ea-1ab7-58b0-26d2-2c393570dd2f>