Re: gcc auto-omit-frame-pointer vs msvc longjmp
Hi, all
I think this issue causes the gdb crash on XP.
You can see the thread: http://sourceware.org/ml/gdb/2011-10/msg00056.html
My many friends and I can reproduce this crash issue, but no problem on Win7.
On Thu, Oct 20, 2011 at 5:05 AM, Bob Breuer wrote:
> 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>: mov 0x4(%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>: mov 0x8(%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
>
--
Best Regards,
xunxun
Re: GCC 4.6.2 Release Candidate available from gcc.gnu.org
I think after the 4.6.2 RC, gfortran' io changed something. The 4.6.2 RC libgfortran section can't be built on mingw/mingw64. It will cause: libtool: compile: i686-w64-mingw32-gcc -L/mingw/i686-w64-mingw32/lib -L/mingw/mingw/lib -isystem /mingw/i686-w64-mingw32/include -isystem /mingw/mingw/include -DHAVE_CONFIG_H -I. -I../.././libgfortran -iquote../.././libgfortran/io -I../.././libgfortran/../gcc -I../.././libgfortran/../gcc/config -I../.././libgfortran/../libquadmath -I../../host-i686-w64-mingw32/gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -ffunction-sections -fdata-sections -g -pipe -O2 -I/mingw/include -MT file_pos.lo -MD -MP -MF .deps/file_pos.Tpo -c ../.././libgfortran/io/file_pos.c -o file_pos.o ../.././libgfortran/io/file_pos.c: In function 'st_flush': ../.././libgfortran/io/file_pos.c:457:20: error: 'stream' has no member named 'fd' The latest 4.6 branch libgfortran has no problem. I would hope you can fix the problem next RC or release. On Wed, Oct 19, 2011 at 8:13 PM, Jakub Jelinek wrote: > GCC 4.6.2 Release Candidate available from gcc.gnu.org > > The first release candidate for GCC 4.6.2 is available from > > ftp://gcc.gnu.org/pub/gcc/snapshots/4.6.2-RC-20111019 > > and shortly its mirrors. It has been generated from SVN revision 180180. > > I have so far bootstrapped and tested the release candidate on > x86_64-linux and i686-linux. Please test it and report any issues to > bugzilla. > > If all goes well, I'd like to release 4.6.2 in the middle of the next week. > -- Best Regards, xunxun
Re: gcc auto-omit-frame-pointer vs msvc longjmp
Hi, all
It seems that gcc's auto-omit-frame-pointer has other problems.
The example is from mingw bug tracker:
http://sourceforge.net/tracker/?func=detail&aid=3426555&group_id=2435&atid=102435
g++ -O3 main.cpp running will crash.
g++ -O2 main.cpp running no crash.
g++ -O3 -fno-omit-frame-pointerrunning no crash.
I don't know in the end which optimize option defaultly contains
this switch "-fomit-frame-pointer" on i686-pc-mingw32 or x86_64-w64-mingw32?
--
Best Regards,
xunxun
#include
typedef void (*Func)(char*);
bool lie = false;
Func dummy = 0;
void moveToWindowsRecycler(const std::vector& filesToDelete =
std::vector()) //throw FileError
{
if (!lie)
throw 1;
char errorMessage[2];
Func fun = lie ? dummy : 0;
fun(errorMessage);
std::vector fileNames;
for (std::vector::const_iterator iter = filesToDelete.begin(); iter !=
filesToDelete.end(); ++iter)
fileNames.push_back(*iter);
}
void wgfdfsdgfsdgfsdg() //throw FileError
{
::moveToWindowsRecycler(); //throw FileError
}
int main()
{
try
{
moveToWindowsRecycler() ;//throw FileError
}
catch (...) {}
return 0;
}
Re: gcc auto-omit-frame-pointer vs msvc longjmp
于 2011/10/22 13:13, xunxun 写道: Hi, all It seems that gcc's auto-omit-frame-pointer has other problems. The example is from mingw bug tracker: http://sourceforge.net/tracker/?func=detail&aid=3426555&group_id=2435&atid=102435 g++ -O3 main.cpp running will crash. g++ -O2 main.cpp running no crash. g++ -O3 -fno-omit-frame-pointerrunning no crash. I don't know in the end which optimize option defaultly contains this switch "-fomit-frame-pointer" on i686-pc-mingw32 or x86_64-w64-mingw32? It crashes on Win7. -- Best Regards, xunxun
Re: gcc 4.7.3 plans?
于 2013/1/29 星期二 19:24, Richard Biener 写道: On Tue, Jan 29, 2013 at 4:09 AM, Kenny Simpson wrote: There have been quite a few fixes on the 4.7 branch since 4.7.2 was released 4 months ago and several of the remaining regression bugs have fixes in trunk. What are the plans for 4.7.3? There will be a 4.7.3 release (shortly) before 4.8.0 releases. There is quite a number of regression fixes that are suitable for backporting to the 4.7 branch still. Richard. thanks, -Kenny The GCC 4.8 branch has been created and a first release candidate is being prepared right now. When will 4.7.3 be released? -- Best Regards, xunxun
Re: GCC 4.8.0 Release Candidate available from gcc.gnu.org
于 2013/3/17 星期日 17:31, niXman 写道: 2013/3/16 Jakub Jelinek: I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. Also tested i686-w64-mingw32 and x86_64-w64-mingw32 . Did you test -flto build? I remembered you came across a LTO issue when using 4.8 some days ealier. -- Best Regards, xunxun
