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

[Bob Breuer]

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 
#include 

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

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

[Bob Breuer]

Kai Tietz wrote:
> 2011/10/17 Bob Breuer :
>> 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 
>> #include 
>>
>> 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?

> 
> This will work as expected with or without omit-frame-pointer.
> 
> The issue is that setjmp has a second (undocumented as usual)
> argument, which has a meaning.

So why does my testcase above fail with the asm, but work without the
asm statement?  Compile it with gcc -O2 and try it yourself.

> 
> Regards,
> Kai
> 
> PS:  _setjmp3 is an export from msvcrt.dll.  So if symbol is missing
> on link, simply specify msvcrt.dll as argument to link-line.

Re: gcc auto-omit-frame-pointer vs msvc longjmp

[Bob Breuer]

Kai Tietz wrote:
> 2011/10/18 Bob Breuer :
>> Kai Tietz wrote:
>>> 2011/10/17 Bob Breuer :
>>>> Richard Henderson wrote:
>>>>> On 10/17/2011 07:09 AM, Bob Breuer wrote:
>>>>>> 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 
>>>> #include 
>>>>
>>>> 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.


We probably have a difference in build or run environment.  I've
double-checked with another machine and can get the same crash in
longjmp when running the test executable on both WinXP and Win2k, but
not on Win7.  So it looks like Microsoft may have changed this "feature"
somewhere between WinXP and Win7.

The msvcrt implementation of longjmp (or at least the one I'm looking
at) does a ebp based access using the saved value of ebp.  Here's the
relevant disassembly of longjmp:

0x7801e6f3 in longjmpex () from C:\WINNT\system32\msvcrt.dll
(gdb) disas
Dump of assembler code for function longjmpex:
   0x7801e6ef <+0>: mov0x4(%esp),%ebx
=> 0x7801e6f3 <+4>: mov(%ebx),%ebp
...
   0x7801e73d <+78>:call   0x7800bd5e 
...
   0x7800bd5e <+56>:push   %ebx
   0x7800bd5f <+57>:push   %ecx
   0x7800bd60 <+58>:mov$0x7803dc64,%ebx
=> 0x7800bd65 <+63>:mov0x8(%ebp),%ecx

It crashes on the access of 0x8(%ebp).  Those are the only 2 places
where this version of longjmp touches ebp.  Is it possible to force a
stackframe by just adding a suitable attribute to either the setjmp
function prototype, or the function which calls setjmp?

Bob

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

[Bob Breuer]

Kai Tietz wrote:
> Hi,
> 
> For trunk-version I have a tentative patch for this issue.  On 4.6.x
> and older branches this doesn't work, as here we can't differenciate
> that easy between ms- and sysv-abi.
> 
> But could somebody give this patch a try?
> 
> Regards,
> Kai
> 
> ChangeLog
> 
> * config/i386/i386.c (ix86_frame_pointer_required): Enforce use of
> frame-pointer for 32-bit ms-abi, if setjmp is used.
> 
> Index: i386.c
> ===
> --- i386.c  (revision 180099)
> +++ i386.c  (working copy)
> @@ -8391,6 +8391,10 @@
>if (SUBTARGET_FRAME_POINTER_REQUIRED)
>  return true;
> 
> +  /* For older 32-bit runtimes setjmp requires valid frame-pointer.  */
> +  if (TARGET_32BIT_MS_ABI && cfun->calls_setjmp)
> +return true;
> +
>/* In ix86_option_override_internal, TARGET_OMIT_LEAF_FRAME_POINTER
>   turns off the frame pointer by default.  Turn it back on now if
>   we've not got a leaf function.  */
> 

For a gcc 4.7 snapshot, this does fix the longjmp problem that I
encountered.  So aside from specifying -fno-omit-frame-pointer for
affected files, what can be done for 4.6?

Bob

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

[Bob Breuer]

Kai Tietz wrote:
> 2011/10/24 Bob Breuer :
>> Kai Tietz wrote:
>>> Hi,
>>>
>>> For trunk-version I have a tentative patch for this issue.  On 4.6.x
>>> and older branches this doesn't work, as here we can't differenciate
>>> that easy between ms- and sysv-abi.
>>>
>>> But could somebody give this patch a try?
>>>
>>> Regards,
>>> Kai
>>>
>>> ChangeLog
>>>
>>> * config/i386/i386.c (ix86_frame_pointer_required): Enforce use of
>>> frame-pointer for 32-bit ms-abi, if setjmp is used.
>>>
>>> Index: i386.c
>>> ===
>>> --- i386.c  (revision 180099)
>>> +++ i386.c  (working copy)
>>> @@ -8391,6 +8391,10 @@
>>>if (SUBTARGET_FRAME_POINTER_REQUIRED)
>>>  return true;
>>>
>>> +  /* For older 32-bit runtimes setjmp requires valid frame-pointer.  */
>>> +  if (TARGET_32BIT_MS_ABI && cfun->calls_setjmp)
>>> +return true;
>>> +
>>>/* In ix86_option_override_internal, TARGET_OMIT_LEAF_FRAME_POINTER
>>>   turns off the frame pointer by default.  Turn it back on now if
>>>   we've not got a leaf function.  */
>>>
>> For a gcc 4.7 snapshot, this does fix the longjmp problem that I
>> encountered.  So aside from specifying -fno-omit-frame-pointer for
>> affected files, what can be done for 4.6?
>>
>> Bob
> 
> Well, for 4.6.x (or older) we just can use the mingw32.h header in
> gcc/config/i386/ and define here a subtarget-macro to indicate that.
> The only incompatible point here might be for Wine using the
> linux-compiler to build Windows related code.
> 
> A possible patch for 4.6 gcc versions I attached to this mail.
> 
> Regards,
> Kai
> 
> Index: mingw32.h
> ===
> --- mingw32.h   (revision 180393)
> +++ mingw32.h   (working copy)
> @@ -239,3 +239,8 @@
>  /* We should find a way to not have to update this manually.  */
>  #define LIBGCJ_SONAME "libgcj" /*LIBGCC_EH_EXTN*/ "-12.dll"
> 
> +/* For 32-bit Windows we need valid frame-pointer for function using
> +   setjmp.  */
> +#define SUBTARGET_SETJMP_NEED_FRAME_POINTER \
> +  (!TARGET_64BIT && cfun->calls_setjmp)
> +
> Index: i386.c
> ===
> --- i386.c  (revision 180393)
> +++ i386.c  (working copy)
> @@ -8741,6 +8741,12 @@
>if (SUBTARGET_FRAME_POINTER_REQUIRED)
>  return true;
> 
> +#ifdef SUBTARGET_SETJMP_NEED_FRAME_POINTER
> +  /* For older 32-bit runtimes setjmp requires valid frame-pointer.  */
> +  if (SUBTARGET_SETJMP_NEED_FRAME_POINTER)
> +return true;
> +#endif
> +
>/* In ix86_option_override_internal, TARGET_OMIT_LEAF_FRAME_POINTER
>   turns off the frame pointer by default.  Turn it back on now if
>   we've not got a leaf function.  */
> 

That works for me. Thanks.

Bob