Note: SA_SIGINFO has now been implemented by Jérémie Koenig. It will be uploaded in Debian eglibc 2.13-19.

IRC, #hurd, August / September 2010:

<giselher> Hy, I came across SA_SIGINFO in cherokee, I have the void sighandler(int num) prototype but how do I add the sa_handler field?
<pinotree> if SA_SIGACTION is not defined, then you use sa_handler instead of sa_sigaction, and not add SA_SIGINFO in the sa_flags
<giselher> SA_SIGINFO is not defined
<pinotree> s/SA_SIGACTION/SA_SIGINFO/ above, yes
<giselher> K
<giselher> I am not sure if I fully understand this, there is the  line "act.sa_flags = SA_SIGINFO" and how do I have to change that >_>
<pinotree> can you paste the source in a pastebin?
<giselher> k
<giselher> http://archhurd.pastebin.com/N8BCnG6g at line 790
<pinotree> something along the lines of http://www.archhurd.pastebin.com/tdpcFD5G
<pinotree> note that in the handler the siginfo_t parameter is used, which cannot be done if SA_SIGINFO is not defined
<pinotree> (that code still won't compile, yet)
<giselher> btw: is there a reason why SA_SIGINFO is not implemented?
<giselher> the guildlines only say "It's not implemented"
<azeem> 09:43 < azeem> signal stuff is tricky :-/
<azeem> basically it was pending on a complete rewrite by Roland, which never occured
<youpi> I have an almost complete implementation, just not finished yet
<youpi> (only the siginfo part)
<azeem> nobody really groked that code for years until youpi showed up, but he added partial support AFAIK, not having much time on his hand
<azeem> ah, he's here
<azeem> :)
<giselher> oh, should I just wait ?
<youpi> no
<giselher> k
<youpi> there are OSes which don't have SA_SIGINFO
<youpi> just cope with them: use sa_handler instead of sa_sigaction, and don't set SA_SIGINFO
<youpi> (i.e. replace with 0 in your example)
<giselher> ok
<youpi> when SA_SIGINFO becomes available, it'll just be used

IRC, freenode, #hurd, 2011-08-20:

< youpi> erf, tcpwrappers will need si_pid
< jkoenig> I could implement it not too far away in the future, we just
  need a version of msg_sig_post() with a siginfo argument or something.
< youpi> I can also see a lot of packages using SA_SIGINFO for no reason...
< youpi> (probably copy/pasty code)
< youpi>   sa.sa_flags = SA_SIGINFO;
< youpi>   sa.sa_handler = parse_config;
< youpi> void parse_config(int)
< youpi> yay
< youpi>     if(siginf->si_signo == SIGXCPU)
< youpi>       fprintf(stderr, "Exceeded CPU usage.\n");
< youpi> ...
< youpi> jkoenig: actually most package don't actually use the SA_SIGINFO
  they request...
< youpi> jkoenig: si_pid should get us almost all actually used coverage
< youpi> I've seen only one example using si_errno
< jkoenig> ok
< youpi> oh, it's actually supported by your patch
< youpi> (errno)
< jkoenig> but I guess since implementing si_pid will require a new RPC, we
  might as well plan for the rest
< youpi> jkoenig: indeed
< jkoenig> youpi, hmm I doubt it's properly filled in in all circumstances?
< youpi> ok, well, we'll see
< pinotree> jkoenig: if it can be of help, boost::unit_test queries various
  fields of siginfo_t depending on the signal
< pinotree> jkoenig: also, pulseaudio uses siginfo_t for remapping faulting
  memory on SIGBUS
< jkoenig> pinotree, oh ok good to know
< pinotree> *faulty
< youpi> jkoenig: well, I guess you had checked that the si_addr field is
  correct in a few simple testcase :)
< jkoenig> hmm I think so, yes
< jkoenig> I ran like, "* (char *) 0x12345678;" or something IIRC
< youpi> ok
< jkoenig> I seem to remember mach generated SIGBUS instead of SIGSEGV
  depending on the upper bit, or something (I can't quite remember)
< jkoenig> but when sigsegv was generated si_addr was right.
< pinotree> jkoenig: (see boost/test/impl/execution_monitor.ipp in boost
  sources)
< pinotree> maybe you can try the unit tests for boost::unit_tests, if any
  :)
< pinotree> (while src/pulsecore/memtrap.c in PA)
 * pinotree stops doing MrObvious™