This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
YEES! It does crash in winxp.
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<abnormal_termination+56> ... 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?
and we had relevant report in ruby. http://redmine.ruby-lang.org/issues/5375
Kai, would you mind if i reopen this bug you rejected? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49230
Bob
-- Regards.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |