From: Stefan Weil <sw@weilnetz.de>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Peter Crosthwaite <crosthwaite.peter@gmail.com>,
QEMU Developer <qemu-devel@nongnu.org>,
Andrew Baumann <Andrew.Baumann@microsoft.com>,
Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH] Use special code for sigsetjmp only in cpu-exec.c
Date: Tue, 1 Mar 2016 14:15:32 +0100 [thread overview]
Message-ID: <56D595F4.50804@weilnetz.de> (raw)
In-Reply-To: <CAFEAcA_g2mYVECDDEVX8Gs_374oL5Qy6t+unpbfaNKd5dT5pLg@mail.gmail.com>
Am 01.03.2016 um 13:22 schrieb Peter Maydell:
> On 1 March 2016 at 11:54, Stefan Weil <sw@weilnetz.de> wrote:
>> Am 01.03.2016 um 10:59 schrieb Peter Maydell:
>>> I don't understand this patch. Why doesn't it work to have
>>> sigsetjmp() be implemented the same way for every use that
>>> QEMU makes of it?
>> It does, as long as the "same way" is the correct one, namely
>> the one without stack unwinding.
>>
>> The current code used to work, but re-arranged include files
>> broke the working code somewhere in the past:
>>
>> include/sysemu/os-win32.h does the right thing at the
>> wrong place. Its correct definition of sigsetjmp is overwritten by
>> the definition from a Mingw-w64 system header file which
>> triggers stack unwinding. Stack unwinding is fatal for
>> QEMU's generated code.
>>
>> My patch makes sure that the critical code in cpu-exec.c
>> gets the correct definition of sigsetjmp.
> I think we should fix this by making sure that osdep.h
> does the right thing -- ie that it gives us the correct
> definition and prevents mingw's headers from overriding it
> with the wrong thing (by ensuring that the offending system
> header is included before we redefine things, or however
> necessary). This is what osdep.h's purpose is -- to hide
> annoying system-header workarounds and hacks rather than
> putting them in the rest of QEMU code.
>
>> In addition, it removes code which might or might not
>> change the default definition of sigsetjmp (depending
>> on the order of include files). Now all other files beside
>> cpu-exec.c will use the default behaviour with stack
>> unwinding.
> That seems wrong -- we should have the same behaviour for
> sigsetjmp/siglongjmp everywhere we use it.
>
> thanks
> -- PMM
Technically there is nothing wrong with using different behaviour
for each setjmp or sigsetjmp.
The "best" solution would be to add any prologue / epilogue which
is needed for stack unwinding to the generated code. Like that,
no tricks with redefinitions of setjmp / sigsetjmp would be necessary.
As long as that solution is not available, I'd prefer the variant which
is implemented by my patch and keep the workaround close to
the single location where it is needed.
Your alternate solution would require
inclusion of setjmp.h in include/sysemu/os-win32.h. Then every
compilation for Windows would get that header file, resulting
in a (small) overhead. In addition, there would be no stack
unwinding for any setjmp/longjmp which is not the standard
behaviour for Windows 64 bit (but which we had until it was
broken). I simply don't know whether this has unwanted
side effects (maybe for debugging or with crash dumps) -
that's the reason why I'd minimize the non-standard behaviour.
Regards,
Stefan
next prev parent reply other threads:[~2016-03-01 13:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-01 5:07 [Qemu-devel] [PATCH] Use special code for sigsetjmp only in cpu-exec.c Stefan Weil
2016-03-01 6:23 ` Andrew Baumann
2016-03-01 9:59 ` Peter Maydell
2016-03-01 11:54 ` Stefan Weil
2016-03-01 12:22 ` Peter Maydell
2016-03-01 13:15 ` Stefan Weil [this message]
2016-03-01 17:46 ` Andrew Baumann
2016-03-01 17:53 ` Paolo Bonzini
2016-03-01 17:54 ` Peter Maydell
2016-03-01 19:08 ` Stefan Weil
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=56D595F4.50804@weilnetz.de \
--to=sw@weilnetz.de \
--cc=Andrew.Baumann@microsoft.com \
--cc=crosthwaite.peter@gmail.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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.