From: Jan Kiszka
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 cpu_single_env in that
On Sat, Jul 2, 2011 at 10:50 AM, Jan Kiszka wrote:
> From: Jan Kiszka
>
> 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,
> causi
On 2011-07-02 11:08, Blue Swirl wrote:
> On Sat, Jul 2, 2011 at 10:50 AM, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> 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 beco
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++;
Thanks, applied.
On Sat, Jul 2, 2011 at 10:50 AM, Jan Kiszka wrote:
> From: Jan Kiszka
>
> 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 fr
On 2 July 2011 08:50, Jan Kiszka wrote:
> From: Jan Kiszka
>
> 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.
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 r
On 11 August 2011 13:16, Paolo Bonzini 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 vari
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 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
>> -Wclobbere
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 I
On 11 August 2011 15:10, Paolo Bonzini 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 also trie
On 11 August 2011 15:10, Paolo Bonzini 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
14 matches
Mail list logo
