From: Riku Voipio <riku.voipio@iki.fi>
To: Jamie Lokier <jamie@shareable.org>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] linux-user: Proper exit code for uncaught signals
Date: Thu, 27 Nov 2008 14:44:06 +0200 [thread overview]
Message-ID: <20081127124406.GA8274@kos.to> (raw)
In-Reply-To: <20081127121615.GC18400@shareable.org>
On Thu, Nov 27, 2008 at 12:16:15PM +0000, Jamie Lokier wrote:
> > > The proper exit code for dieing from an uncaught signal is -<signal>.
> > > The kernel doesn't allow exit() or _exit() to pass a negative value.
> > > To get the proper exit code we need to actually die from an uncaught
> > > signal.
>
> It's nothing like -<signal>, so the comment should be changed.
Something like:
Proper exit code for dieing from an uncaught signal differs from normal
exit, so applications using WISIGNALED/WTERMSIG don't get the expected
result. The proper way is to actually die from an uncaught signal.
> The general principle of sending yourself a signal to get the right
> exit status is good.
> > > + sigfillset(&act.sa_mask);
> > > + act.sa_handler = SIG_DFL;
> > > + sigaction(host_sig, &act, NULL);
>
> What if the SIG_DFL _host_ behaviour is not to terminate the host
> process, but it has terminated the guest process? Awkward one.
Could this happen on Linux or is this a portability issue?
> > > + /* For some reason raise(host_sig) doesn't send the signal when
> > > + * statically linked on x86-64. */
> > > + kill(getpid(), host_sig);
> Is getpid() always right here, and should tgkill() or tkill() be used when
> clone is supported?
I'll have to look into this. The thought that this code needs to
do multithreaded signal handling (preferredly in a portable fashion)
feels like I'm heading towards endless swamplands..
--
"rm -rf" only sounds scary if you don't have backups
next prev parent reply other threads:[~2008-11-27 12:44 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-23 21:37 [Qemu-devel] [PATCH] linux-user: Proper exit code for uncaught signals Riku Voipio
2008-11-27 11:42 ` Thiemo Seufer
2008-11-27 12:16 ` Jamie Lokier
2008-11-27 12:44 ` Riku Voipio [this message]
2008-11-27 12:21 ` Riku Voipio
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081127124406.GA8274@kos.to \
--to=riku.voipio@iki.fi \
--cc=jamie@shareable.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.