Nick Kledzik
2009-Sep-18 21:40 UTC
[LLVMdev] OT: intel darwin losing primary target status
I thought of another work around. The FSF gcc driver can implicitly add -no_compact_unwind to the link line. This tells the linker to not produce compact unwind information from the dwarf unwind info in .o files. Then at runtime the darwin unwinder will fallback and use the slow dwarf unwind info. -Nick On Sep 18, 2009, at 2:27 PM, Nick Kledzik wrote:> I dug into this. Based on the .s files in bugzilla, the latest gcc is > now adding dwarf unwind info to describe the function epilog. If you > run dwarfdump --eh-frame on the .o files made with the new compiler, > you'll see extra dwarf unwind instructions at the end like: > > ... > DW_CFA_advance_loc4 (64) #<-- advance to near end of > function > DW_CFA_restore (rbp) > DW_CFA_def_cfa (rsp, 8) > DW_CFA_nop > DW_CFA_nop > > The linker's conversion to compact unwind "runs" the dwarf unwind info > for a function and then records the state at the end. Adding unwind > info for the epilog breaks this. In the long term, I can add > heuristics to the linker to detect that what looks like unwind info > for the epilog and stop processing the dwarf instructions. > > The short term fix for gcc is to *not* add epilog unwind information > for Darwin. > > Epilog unwind information is never needed for exception processing. > Its only use is for debugging or sampling when you want to > asynchronously make a stack back trace. > > -Nick > > On Sep 18, 2009, at 11:40 AM, Jack Howarth wrote: >> I am not sure if some of these problems were latent and only >> exposed by the change, but the mass regressions in the g++ >> and libjava testsuites were triggered by the commit... >> >> Author: rth >> Date: Sat May 30 00:33:46 2009 >> New Revision: 147995 >> >> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147995 > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Jack Howarth
2009-Sep-18 23:28 UTC
[LLVMdev] OT: intel darwin losing primary target status
On Fri, Sep 18, 2009 at 02:40:17PM -0700, Nick Kledzik wrote:> I thought of another work around. The FSF gcc driver can implicitly > add -no_compact_unwind to the link line. This tells the linker to not > produce compact unwind information from the dwarf unwind info in .o > files. Then at runtime the darwin unwinder will fallback and use the > slow dwarf unwind info. > > -Nick >Nick, Thanks! I have asked Richard to propose a patch to disable the additional epilog info on darwin. While we are on the topic of eh issues on darwin, could you take a look at PR37012? On darwin9/10. we have the following remaining failures in gcc-4.4.1 at -m32... FAIL: g++.dg/torture/stackalign/eh-alloca-1.C -O3 -g execution test FAIL: g++.dg/torture/stackalign/eh-vararg-1.C -O3 -g execution test FAIL: g++.dg/torture/stackalign/eh-vararg-2.C -O3 -g execution test FAIL: g++.dg/torture/stackalign/throw-1.C -O3 -g execution test FAIL: g++.dg/torture/stackalign/throw-2.C -O3 -g execution test FAIL: g++.dg/torture/stackalign/throw-3.C -O3 -g execution test FAIL: g++.dg/torture/stackalign/eh-alloca-1.C -O3 -g execution test FAIL: g++.dg/torture/stackalign/eh-vararg-1.C -O3 -g execution test FAIL: g++.dg/torture/stackalign/eh-vararg-2.C -O3 -g execution test FAIL: g++.dg/torture/stackalign/throw-1.C -O3 -g execution test FAIL: g++.dg/torture/stackalign/throw-2.C -O3 -g execution test FAIL: g++.dg/torture/stackalign/throw-3.C -O3 -g execution test These eh failures are really weird because they are triggered by the -g option. Without -g, the resulting test cases pass their execution tests fine. The problem doesn't exist for -m64 (with or without -g). I posted assembly files for these testcases at the various combinations (-m32 -O3, -m32 -O3 -g, -m64 -O3 -g, -m64 -O3)... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37012#c48 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37012#c49 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37012#c50 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37012#c51 Perhaps if you diff the assembly files, you might recognize the problem in that one as well. Jack
Jack Howarth
2009-Sep-19 03:19 UTC
[LLVMdev] OT: intel darwin losing primary target status
On Fri, Sep 18, 2009 at 02:40:17PM -0700, Nick Kledzik wrote:> I thought of another work around. The FSF gcc driver can implicitly > add -no_compact_unwind to the link line. This tells the linker to not > produce compact unwind information from the dwarf unwind info in .o > files. Then at runtime the darwin unwinder will fallback and use the > slow dwarf unwind info. > > -Nick >Nick, I can confirm that passing "-Wl,-no_compact_unwind" to the failing testcase for g++.dg/torture/stackalign/eh-vararg-2.C eliminates the run-time error. I'd run the entire testsuite with that approach but I don't know how to suppress the comma in... make -k check RUNTESTFLAGS="--target_board=unix'{-Wl,-no_compact_unwind}'" so that it runs as a single test passing "-Wl,-no_compact_unwind". Jack
Jack Howarth
2009-Sep-19 06:27 UTC
[LLVMdev] OT: intel darwin losing primary target status
On Fri, Sep 18, 2009 at 02:40:17PM -0700, Nick Kledzik wrote:> I thought of another work around. The FSF gcc driver can implicitly > add -no_compact_unwind to the link line. This tells the linker to not > produce compact unwind information from the dwarf unwind info in .o > files. Then at runtime the darwin unwinder will fallback and use the > slow dwarf unwind info. > > -Nick >Nick, FYI, executing... make -k check RUNTESTFLAGS="--target_board=unix/-Wl,-no_compact_unwind" reveals that this approach in fact eliminates all of the eh regressions in gcc trunk. Unfortunately, it plays havoc with the gcc.dg/pch and g++.dg/pch test cases causing hundreds of new failures of the form... FAIL: ./common-1.h -O0 -g (test for excess errors) FAIL: gcc.dg/pch/common-1.c -O0 -g FAIL: gcc.dg/pch/common-1.c -O0 -g assembly comparison Executing on host: /sw/src/fink.build/gcc45-4.4.999-20090914/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc45-4.4.999-20090914/darwin_objdir/gcc/ ./common-1.h -O0 -g -Wl,-no_compact_unwind -o common-1.h.gch (timeout = 300) Undefined symbols: "_main", referenced from: start in crt1.10.5.o ld: symbol(s) not found collect2: ld returned 1 exit status compiler exited with status 1 output is: Undefined symbols: "_main", referenced from: start in crt1.10.5.o ld: symbol(s) not found collect2: ld returned 1 exit status FAIL: ./common-1.h -O0 -g (test for excess errors) Excess errors: Undefined symbols: "_main", referenced from: start in crt1.10.5.o ld: symbol(s) not found pch file 'common-1.h.gch' missing FAIL: gcc.dg/pch/common-1.c -O0 -g assembly file 'common-1.s' missing FAIL: gcc.dg/pch/common-1.c -O0 -g assembly comparison Jack
Daniel Dunbar
2009-Sep-19 07:13 UTC
[LLVMdev] OT: intel darwin losing primary target status
On Fri, Sep 18, 2009 at 8:19 PM, Jack Howarth <howarth at bromo.med.uc.edu> wrote:> On Fri, Sep 18, 2009 at 02:40:17PM -0700, Nick Kledzik wrote: >> I thought of another work around. The FSF gcc driver can implicitly >> add -no_compact_unwind to the link line. This tells the linker to not >> produce compact unwind information from the dwarf unwind info in .o >> files. Then at runtime the darwin unwinder will fallback and use the >> slow dwarf unwind info. >> >> -Nick >> > > Nick, > I can confirm that passing "-Wl,-no_compact_unwind" to the failing > testcase for g++.dg/torture/stackalign/eh-vararg-2.C eliminates the > run-time error. I'd run the entire testsuite with that approach but > I don't know how to suppress the comma in... > > make -k check RUNTESTFLAGS="--target_board=unix'{-Wl,-no_compact_unwind}'"Perhaps try using -Xlinker? - Daniel
Jack Howarth
2009-Sep-20 23:22 UTC
[LLVMdev] OT: intel darwin losing primary target status
On Fri, Sep 18, 2009 at 02:40:17PM -0700, Nick Kledzik wrote:> I thought of another work around. The FSF gcc driver can implicitly > add -no_compact_unwind to the link line. This tells the linker to not > produce compact unwind information from the dwarf unwind info in .o > files. Then at runtime the darwin unwinder will fallback and use the > slow dwarf unwind info. > > -Nick >Nick, The second approach of passing -no_compact_unwind produced excellent results... http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg01761.html ...eliminating all of the eh regressions in gcc trunk as well as a few failures in the libjava testsuite present since gcc 4.4. I've submitted this change for gcc 4.5... http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01327.html Hopefully FSF won't break backward compatibility with the non-compact unwind any time soon. Jack ps How does the llvm project intend to handle this issue on the linux side for llvm-gcc-4.2 and clang? Eventually the libgcc used by the llvm projects and FSF gcc will fork irreversibly, no? I guess one would have to resort to a llvm compiler-plugin for FSF gcc and not attempt to mix code with clang/llvm-gcc-4.2 in that case.