siginfo_t content

[John Baldwin]

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