[patch] Fix oddity in personality routine

Sat Dec 5 06:54:00 GMT 2009

On Fri, Dec 04, 2009 at 03:57:11PM +0000, Bryce McKinlay wrote:
> On Fri, Dec 4, 2009 at 3:48 PM, Andrew Haley <aph@redhat.com> wrote:
>> > Yes, which is why I suggested you use SYSTEMSPEC.  (Twice now, I think.  :-)
> >
> > SYSTEMSPEC should pass that flag to everything liked with gcj.
>> Jack,
>> Here's a patch that adds the allow_stack_execute flag to SYSTEMSPEC as
> suggested by Andrew.
>> It does not fix the problem with ecj, but I agree it's a good idea.
>> Bryce

Bryce,
 Your patch eliminates the crashes in gcj completely for gcc trunk
on x86_64-apple-darwin9 if I also regress out r154282 and r154283
so that the FSF libgcc's unwinder is used again. So we are starting
to peel the layers off of the problem. Your patch definitely should
go into gcc trunk and gcc 4.4 branch (where it will be immediately
useful on darwin9 since the libgcc_ext changes don't exist there).
 In case you are unaware, the r154282 and r154283 commits
introduced a new libgcc_ext shared library on darwin to provide
the additional symbols that have been added to libgcc since the
libgcc 10.4 and 10.5 stubs were defined. One 'feature' of this
change is that both the system libgcc and the FSF libgcc are linked
in. The logic is that since the 10.4/10.5 stubs are no longer built
on FSF gcc trunk, those symbols will be provided by the first 
libgcc to be linked in (which is the system's). The second libgcc_s
linked in comes from FSF gcc and provides the additional symbols
via the 10.4/10.5 libgcc_ext stubs. Mike Stump approved the logic
of all of this.
 I will revert back to the r154282 and r154283 commits being
in place under darwin9. When the system libgcc is used under
darwin9 (which is now the default behavior in gcc trunk for
darwin), gcj crashes with your patch in place when compiling
java code...
Breakpoint 1 (./../../gcc-4.5-20091204/libjava/exception.cc:128) pending.
(gdb) r testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccamdOl5.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccaNqaGi.jar
Starting program: /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin9.8.0/4.5.0/ecj1 testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccamdOl5.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccaNqaGi.jar
warning: posix_spawn failed, trying execvp, error: 86
Reading symbols for shared libraries ++++.+. done
Program received signal SIGABRT, Aborted.
0x00007fff810c3f16 in __kill ()
(gdb) bt
#0 0x00007fff810c3f16 in __kill ()
#1 0x00007fff81134f6d in abort ()
#2 0x000000010001342b in _Jv_Throw (value=0x10483e6c0) at ../../../gcc-4.5-20091204/libjava/exception.cc:128
Previous frame inner to this frame (gdb could not unwind past this frame)
This crash appears to be different from that seen under darwin10. That might not be surprising as the
unwinder is a different one subsumed into libSystem in that case. Unfortunately it won't be trivial
to get debug code for the system unwinder. Hopefully, I can just use the approach of examining the
assembly at the address of the crash to define the scope of the problem in both darwin9 and darwin10.
In any case, we have made significant progress towards solving PR41991. Thanks in advance for
any help in getting your patch into gcc trunk and 4.4 branch as an obvious fix.
 Jack