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 _______________________________________________ freebsd-chat@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-chat To unsubscribe, send any mail to "freebsd-chat-unsubscr...@freebsd.org"