This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/52444] gcc.dg/tree-prof/pr44777.c execution, -fprofile-generate -D_PROFILE_GENERATE fails at -m32
- From: "howarth at nitro dot med.uc.edu" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sat, 15 Dec 2012 14:02:23 +0000
- Subject: [Bug c/52444] gcc.dg/tree-prof/pr44777.c execution, -fprofile-generate -D_PROFILE_GENERATE fails at -m32
- Auto-submitted: auto-generated
- References: <bug-52444-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52444
--- Comment #1 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-12-15 14:02:23 UTC ---
This issue doesn't occur under darwin10 but when object files, created under
darwin10, are linked under darwin12 this runtime failure occurs. I opened
radar://12875171 in case this was a darwin linker bug. The darwin linker
developer looked at this crash and had the following comments...
This is a (gcc) compiler bug. The crash is because register EBX is wrong in
function x() after returning from the call to function y(). Function y() has
some fancy jumps to labels. After recursing 1000 times, it returns but does so
via messing with the stack frame:
LM6:
movl %ecx, %eax
leal L5-L00000000001$pb(%ebx), %edx
movl (%eax), %ebp
movl 4(%eax), %esp
jmp *%edx
This code does not restore EBX. On runtimes in which EBX is the same for all
functions (e.g pointer to GOT), not restoring EBX will work. But on Mac OS X,
EBX is different in every function. Once it is trashed upon returning to x(),
x stores some memory values via EBX. It is doing the stores to the wrong
location, causing a later crash.
It worked with the SL linker by luck. The smashers happened to be written to
non-critical areas (__gcov_var).