qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Blue Swirl <blauwirbel@gmail.com>, TeLeMan <geleman@gmail.com>,
	Jan Kiszka <jan.kiszka@web.de>,
	qemu-devel <qemu-devel@nongnu.org>,
	David Gilbert <david.gilbert@linaro.org>
Subject: Re: [Qemu-devel] [PATCH] tcg: Reload local variables after return from longjmp
Date: Thu, 11 Aug 2011 13:40:27 +0100	[thread overview]
Message-ID: <CAFEAcA8m1CvqZLqK5Jk1KE9rkpsK0_D8rO9GCdFigWS9RupU7g@mail.gmail.com> (raw)
In-Reply-To: <4E43C80B.1050300@redhat.com>

On 11 August 2011 13:16, Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 08/11/2011 01:30 PM, Peter Maydell wrote:
>> Can you give more details of what compiler/platform this was
>> a problem for? My reading of the C standard is that the compiler
>> isn't allowed to trash env across this longjmp, because it's
>> a variable of automatic scope which isn't modified between the
>> setjmp and the longjmp...
>
> longjmp can destroy any non-volatile variable (-Wclobbered warns about
> this).

"All accessible objects have values [...] as of the time the longjmp
function was called, except that the values of objects of automatic
storage duration that are local to the function containing the
invocation of the corresponding setjmp macro that do not have
volatile-qualified type and have been changed between the setjmp
invocation and longjmp call are indeterminate."
 -- C99 section 7.13.2.1 para 3.

So variables may only be destroyed if they are all of:
 * local to the function calling setjmp
 * not volatile
 * changed between setjmp and longjmp

We don't change env between the setjmp and longjmp so the compiler
should not trash it. (Indeed according to Jan in
http://lists.gnu.org/archive/html/qemu-devel/2011-07/msg00144.html
-Wclobbered doesn't complain about this code.)

-- PMM

  reply	other threads:[~2011-08-11 12:40 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-30 16:47 [Qemu-devel] "cpu-exec.c: avoid AREG0 use" breaks x86 emulation on x86-64 Jan Kiszka
2011-06-30 21:17 ` Stefan Weil
2011-07-01  1:44 ` TeLeMan
2011-07-01 20:15   ` Blue Swirl
2011-07-02  7:50     ` [Qemu-devel] [PATCH] tcg: Reload local variables after return from longjmp Jan Kiszka
2011-07-02  9:08       ` Blue Swirl
2011-07-02  9:43         ` Jan Kiszka
2011-07-03 14:09           ` Paolo Bonzini
2011-07-12 20:56       ` Blue Swirl
2011-08-11 11:30       ` Peter Maydell
2011-08-11 12:16         ` Paolo Bonzini
2011-08-11 12:40           ` Peter Maydell [this message]
2011-08-11 13:13             ` Paolo Bonzini
2011-08-11 13:31               ` Peter Maydell
2011-08-11 14:10                 ` Paolo Bonzini
2011-08-11 14:12                   ` David Gilbert
2011-08-11 14:24                   ` Peter Maydell
2011-08-11 14:32                     ` Paolo Bonzini

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=CAFEAcA8m1CvqZLqK5Jk1KE9rkpsK0_D8rO9GCdFigWS9RupU7g@mail.gmail.com \
    --to=peter.maydell@linaro.org \
    --cc=blauwirbel@gmail.com \
    --cc=david.gilbert@linaro.org \
    --cc=geleman@gmail.com \
    --cc=jan.kiszka@web.de \
    --cc=pbonzini@redhat.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).