Re: [Qemu-devel] gcc auto-omit-frame-pointer vs msvc longjmp

[Kai Tietz]

2011/10/18 Bob Breuer <address@hidden>:
> Kai Tietz wrote:
>> 2011/10/17 Bob Breuer <address@hidden>:
>>> Richard Henderson wrote:
>>>> On 10/17/2011 07:09 AM, Bob Breuer wrote:
>>>>> I don't think this is a free/g_free issue.  If I use the following
>>>>> patch, then I at least get the openbios messages:
>>>>>
>>>>> diff --git a/cpu-exec.c b/cpu-exec.c
>>>>> index a9fa608..dfbd6ea 100644
>>>>> --- a/cpu-exec.c
>>>>> +++ b/cpu-exec.c
>>>>> @@ -180,6 +180,7 @@ static void cpu_handle_debug_exception(CPUState
>>>>>  /* main execution loop */
>>>>>
>>>>>  volatile sig_atomic_t exit_request;
>>>>> +register void *ebp asm("ebp");
>>>>>
>>>>>  int cpu_exec(CPUState *env)
>>>>>  {
>>>>> @@ -233,6 +234,8 @@ int cpu_exec(CPUState *env)
>>>>>
>>>>>      /* prepare setjmp context for exception handling */
>>>>>      for(;;) {
>>>>> +        int dummy = 0;
>>>>> +        ebp = &dummy;
>>>> See if
>>>>
>>>>   asm("" : : : "ebp");
>>>>
>>>> also solves the problem.
>>> No, that doesn't fix it.
>>>
>>>>> Google finds a mention of longjmp failing with -fomit-frame-pointer:
>>>>> http://lua-users.org/lists/lua-l/2005-02/msg00158.html
>>>>>
>>>>> Looks like gcc 4.6 turns on -fomit-frame-pointer by default.
>>>> Hmm.  This is the first I've heard of a longjmp implementation
>>>> failing without a frame pointer.  Presumably this is with the
>>>> mingw i.e. msvc libc?
>>> Yeah, mingw from www.mingw.org which I believe uses msvcrt.dll, package
>>> gcc-core-4.6.1-2-mingw32-bin.
>>>
>>>> This is something that could be worked around in gcc, I suppose.
>>>> We recognize longjmp for some things, we could force the use of
>>>> a frame pointer for msvc targets too.
>>>>
>>>> For now it might be best to simply force -fno-omit-frame-pointer
>>>> for mingw host in the configure script.
>>> Here's a testcase that crashes on the longjmp:
>>>
>>> #include <stdio.h>
>>> #include <setjmp.h>
>>>
>>> jmp_buf env;
>>>
>>> int test(void)
>>> {
>>>  int i;
>>>
>>>  asm("xor %%ebp,%%ebp" ::: "ebp");
>>>
>>>  i = setjmp(env);
>>>  printf("i = %d\n", i);
>>>
>>>  if (i == 0)
>>>    longjmp(env, 2);
>>>
>>>  return i;
>>> }
>>>
>>> int main(void)
>>> {
>>>  return test();
>>> }
>>>
>>> Remove the asm statement to make it not crash.  Obviously with
>>> omit-frame-pointer, gcc can shove anything into ebp.
>>>
>>> Bob
>>
>> This crash isn'r related to ebp existing, or not. The issue is the
>> hidden argument of setjmp, which is missing.  If you can try the
>> following at top of file after include section.
>>
>> #define setjmp(BUF) _setjmpex((BUF), NULL)
>> int __cdecl __attribute__ ((__nothrow__,__returns_twice__))
>> _setjmp3(jmp_buf _Buf, void *_Ctx);
>> ...
>
> Did you mean _setjmp3 instead of _setjmpex?  With _setjmp3, it works
> without the asm, but still crashes if I zero out ebp before the setjmp.
>  Aren't the function arguments on the stack anyway?

Yes, I mean _setjmp3 (pasto from headers and missed the second line
prototyping _setjmp3).
I repeat myself here.  setjmp() has an hidden arguement, which is
passed on x86 on stack.  By not passing this required argument, setjmp
will take a random-value from stack.  In your case 'i'.  btw if you
would pre-initialize 'i' with zero, I would assume you won't see a
crash, but anyway this is just by chance.
For this I suggest to use here _setjmp3 instead, as here
second-argument is documented as being present.

Btw I tested your code with i686-pc-mingw32 version 4.6.x and 4.7.x
gcc version.  With my suggested pattern, I don't see a crash for your
provide test-code with, or without zero-ing ebp.

Kai