From 49a086299e047b18280457b654790ef4a2e5abfa Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Wed, 18 Feb 2015 00:58:35 +0100 Subject: Revert "rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn" This reverts commit 95878586ec7611791f4001a4ee17abf943fae3c1. --- open_issues/sa_siginfo_sa_sigaction.mdwn | 96 ++++++++++++++++++++++++++++++++ 1 file changed, 96 insertions(+) create mode 100644 open_issues/sa_siginfo_sa_sigaction.mdwn (limited to 'open_issues/sa_siginfo_sa_sigaction.mdwn') diff --git a/open_issues/sa_siginfo_sa_sigaction.mdwn b/open_issues/sa_siginfo_sa_sigaction.mdwn new file mode 100644 index 00000000..4e1fa849 --- /dev/null +++ b/open_issues/sa_siginfo_sa_sigaction.mdwn @@ -0,0 +1,96 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="SA_SIGINFO, SA_SIGACTION"]] + +[[!tag open_issue_glibc]] + +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: + + 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? + if SA_SIGACTION is not defined, then you use sa_handler instead of sa_sigaction, and not add SA_SIGINFO in the sa_flags + SA_SIGINFO is not defined + s/SA_SIGACTION/SA_SIGINFO/ above, yes + K + 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 >_> + can you paste the source in a pastebin? + k + http://archhurd.pastebin.com/N8BCnG6g at line 790 + something along the lines of http://www.archhurd.pastebin.com/tdpcFD5G + note that in the handler the siginfo_t parameter is used, which cannot be done if SA_SIGINFO is not defined + (that code still won't compile, yet) + btw: is there a reason why SA_SIGINFO is not implemented? + the guildlines only say "It's not implemented" + 09:43 < azeem> signal stuff is tricky :-/ + basically it was pending on a complete rewrite by Roland, which never occured + I have an almost complete implementation, just not finished yet + (only the siginfo part) + nobody really groked that code for years until youpi showed up, but he added partial support AFAIK, not having much time on his hand + ah, he's here + :) + oh, should I just wait ? + no + k + there are OSes which don't have SA_SIGINFO + just cope with them: use sa_handler instead of sa_sigaction, and don't set SA_SIGINFO + (i.e. replace with 0 in your example) + ok + 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™ -- cgit v1.2.3