Re: Time to Upgrade Qt5
Amit Yaron writes: > Unfortunately, tools such as VLC and VirtualBox don't tell us when > it's time to upgrade Qt5. I came across the same problem with the "nextcloudclient". Luckily enough, the "nextcloudcmd" command works without Qt5. -- Christian Barthel ___ 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"
Re: siginfo_t content
John Baldwin writes: > On 2/15/19 8:43 AM, Christian Barthel wrote: >> John Baldwin 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 ___ 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"
Re: siginfo_t content
John Baldwin 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? -- Christian Barthel ___ 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"
siginfo_t content
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:
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).
Kind regards,
--
Christian Barthel
___
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"
