On 2 July 2011 08:50, Jan Kiszka jan.kis...@web.de wrote:
From: Jan Kiszka jan.kis...@siemens.com
Recent compilers look deep into cpu_exec, find longjmp as a noreturn
function and decide to smash some stack variables as they won't be used
again. This may lead to env becoming invalid after
On 08/11/2011 01:30 PM, Peter Maydell wrote:
Recent compilers look deep into cpu_exec, find longjmp as a noreturn
function and decide to smash some stack variables as they won't be used
again. This may lead to env becoming invalid after return from setjmp,
causing crashes. Fix it by
On 11 August 2011 13:16, Paolo Bonzini pbonz...@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
On 08/11/2011 02:40 PM, Peter Maydell wrote:
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
On 11 August 2011 14:13, Paolo Bonzini pbonz...@redhat.com wrote:
On 08/11/2011 02:40 PM, Peter Maydell wrote:
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
On 08/11/2011 03:31 PM, Peter Maydell wrote:
Then it's a compiler bug, not smartness. Making env volatile
(or making a volatile copy if there is a performance impact)
should still be enough to work around it.
Yes. (It would have to be a volatile copy, I think, env is a function
parameter and
On 11 August 2011 15:10, Paolo Bonzini pbonz...@redhat.com wrote:
I'm not sure about what to read from there:
If I make cpu_single_env thread local with __thread and leave
0d101... in, then again it works reliably on 32bit Lucid, and is
flaky on 64 bit Oneiric (5/10 2 hangs, 3 segs)
I've
On 11 August 2011 15:10, Paolo Bonzini pbonz...@redhat.com wrote:
On 08/11/2011 03:31 PM, Peter Maydell wrote:
Then it's a compiler bug, not smartness. Making env volatile
(or making a volatile copy if there is a performance impact)
should still be enough to work around it.
Yes. (It would
On 08/11/2011 04:24 PM, Peter Maydell wrote:
I cannot think off-hand of a reason why thread-local cpu_single_env should
not work for iothread under Unix, BTW. Since cpu_single_env is only
set/used by a thread at a time (under the global lock), its users cannot
distinguish between a thread-local
Thanks, applied.
On Sat, Jul 2, 2011 at 10:50 AM, Jan Kiszka jan.kis...@web.de wrote:
From: Jan Kiszka jan.kis...@siemens.com
Recent compilers look deep into cpu_exec, find longjmp as a noreturn
function and decide to smash some stack variables as they won't be used
again. This may lead to
On 07/02/2011 11:43 AM, Jan Kiszka wrote:
static const char *pch;
+static char *saved_key;
static jmp_buf expr_env;
#define MD_TLONG 0
@@ -4254,8 +4255,11 @@ static const mon_cmd_t *monitor_parse_command(Monitor
*mon,
}
typestr++;
From: Jan Kiszka jan.kis...@siemens.com
Recent compilers look deep into cpu_exec, find longjmp as a noreturn
function and decide to smash some stack variables as they won't be used
again. This may lead to env becoming invalid after return from setjmp,
causing crashes. Fix it by reloading env from
On Sat, Jul 2, 2011 at 10:50 AM, Jan Kiszka jan.kis...@web.de wrote:
From: Jan Kiszka jan.kis...@siemens.com
Recent compilers look deep into cpu_exec, find longjmp as a noreturn
function and decide to smash some stack variables as they won't be used
again. This may lead to env becoming
On 2011-07-02 11:08, Blue Swirl wrote:
On Sat, Jul 2, 2011 at 10:50 AM, Jan Kiszka jan.kis...@web.de wrote:
From: Jan Kiszka jan.kis...@siemens.com
Recent compilers look deep into cpu_exec, find longjmp as a noreturn
function and decide to smash some stack variables as they won't be used
14 matches
Mail list logo
