Hi all,
This is a (very) rough patch to fix building LLVM with exceptions on
PPC Darwin. Basically, it puts the burden of adding the "--enable-eh"
on the specific target, which is where I think it should go.
If this is okay, then I can clean the patch up and submit it.
-bw
Index: gcc/llvm-backend.cpp
==================================================================---
gcc/llvm-backend.cpp (revision 41554)
+++ gcc/llvm-backend.cpp (working copy)
@@ -122,9 +122,6 @@
Args.push_back("--debug-pass=Structure");
if (flag_debug_pass_arguments)
Args.push_back("--debug-pass=Arguments");
-// Breaks the x86-darwin build
-// if (flag_exceptions)
-// Args.push_back("--enable-eh");
// If there are options that should be passed through to the LLVM backend
// directly from the command line, do so now. This is mainly for debugging
[bwendling:llvm-eh] svn diff gcc/config/linux.h
Index: gcc/config/linux.h
==================================================================---
gcc/config/linux.h (revision 41554)
+++ gcc/config/linux.h (working copy)
@@ -113,8 +113,9 @@
if (flag_pic) \
argvec.push_back ("--relocation-model=pic"); \
else \
- argvec.push_back ("--relocation-model=static");
-
+ argvec.push_back ("--relocation-model=static"); \
+ if (flag_exceptions) \
+ argvec.push_back("--enable-eh")
#endif
/* APPLE LOCAL end LLVM */
[bwendling:llvm-eh] svn diff gcc/config/i386/i386.h
Index: gcc/config/i386/i386.h
==================================================================---
gcc/config/i386/i386.h (revision 41554)
+++ gcc/config/i386/i386.h (working copy)
@@ -481,6 +481,10 @@
#define TARGET_TLS_DIRECT_SEG_REFS_DEFAULT 0
#endif
+#define LLVM_SET_EXCEPTION_OPTION(argvec) \
+ if (flag_exceptions) \
+ argvec.push_back("--enable-eh")
+
/* Once GDB has been enhanced to deal with functions without frame
pointers, we can change this to allow for elimination of
the frame pointer in leaf functions. */
[bwendling:llvm-eh] svn diff gcc/config/rs6000/rs6000.h
Index: gcc/config/rs6000/rs6000.h
==================================================================---
gcc/config/rs6000/rs6000.h (revision 41554)
+++ gcc/config/rs6000/rs6000.h (working copy)
@@ -26,6 +26,8 @@
/* Definitions for the object file format. These are set at
compile-time. */
+#define LLVM_SET_EXCEPTION_OPTION(argvec)
+
#define OBJECT_XCOFF 1
#define OBJECT_ELF 2
#define OBJECT_PEF 3
[bwendling:llvm-eh] svn diff gcc/config/darwin.h
Index: gcc/config/darwin.h
==================================================================---
gcc/config/darwin.h (revision 41554)
+++ gcc/config/darwin.h (working copy)
@@ -1712,11 +1712,13 @@
darwin_objc_llvm_implicit_target_global_var_section(decl) : 0)
const char *darwin_objc_llvm_implicit_target_global_var_section(tree);
-#define LLVM_SET_TARGET_OPTIONS(argvec) \
- if (flag_pic) \
- argvec.push_back ("--relocation-model=pic"); \
- else if (!MACHO_DYNAMIC_NO_PIC_P) \
- argvec.push_back ("--relocation-model=static")
+#define LLVM_SET_TARGET_OPTIONS(argvec) do { \
+ if (flag_pic) \
+ argvec.push_back ("--relocation-model=pic"); \
+ else if (!MACHO_DYNAMIC_NO_PIC_P) \
+ argvec.push_back ("--relocation-model=static"); \
+ LLVM_SET_EXCEPTION_OPTION(argvec); \
+ } while (0)
#endif
/* APPLE LOCAL end LLVM */
Hi Bill,> This is a (very) rough patch to fix building LLVM with exceptions on > PPC Darwin. Basically, it puts the burden of adding the "--enable-eh" > on the specific target, which is where I think it should go.I don't like it. LLVM has plenty of features that are not supported on all targets, why should it be the responsability of llvm-gcc to manage this particular one and not the others? It is true that llvm-gcc is currently the only producer of eh intrinsics. But hopefully this will not always be the case; must all front-ends to LLVM manage -enable-eh? If LLVM doesn't support exception handling for a target then -enable-eh causes eh code to be lowered to nothing. It seems to me that problem with x86-darwin is that LLVM thinks eh is supported but it isn't. Why not simply set SupportsExceptionHandling to false for that target? Ciao, Duncan.
On Aug 28, 2007, at 11:20 PM, Duncan Sands wrote:> Hi Bill, > >> This is a (very) rough patch to fix building LLVM with exceptions on >> PPC Darwin. Basically, it puts the burden of adding the "--enable-eh" >> on the specific target, which is where I think it should go. > > I don't like it. LLVM has plenty of features that are not supported > on all targets, why should it be the responsability of llvm-gcc to > manage > this particular one and not the others? It is true that llvm-gcc is > currently the only producer of eh intrinsics. But hopefully this will > not always be the case; must all front-ends to LLVM manage -enable-eh? > If LLVM doesn't support exception handling for a target then - > enable-eh > causes eh code to be lowered to nothing. It seems to me that > problem with > x86-darwin is that LLVM thinks eh is supported but it isn't. Why > not simply > set SupportsExceptionHandling to false for that target?I agree with Duncan: can't the target (which knows the capabilities of the currently selected subtarget) set the value of SupportsExceptionHandling correctly? -Chris
Hello, Bill> It may be my lack of understanding, but it appears that having -- > enable-eh set during compilation of llvm-gcc is causing extra files > to be compiled.Oh, no. They are always compiled.> They do. However, it doesn't seem to stop it from failing during > compilation of unwind-dw2.c for libgcc -- it has > "__builtin_eh_return" in it. During 4-way FAT PPC compilation, it > tries to compile this file and fails during the LowerOperation > function. Turning --enable-eh off makes the error go away.Could you please send me .bc, which fails? I'll try to figure out, what is going wrong. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.
On 8/29/07, Anton Korobeynikov <asl at math.spbu.ru> wrote:> Hello, Bill > > > It may be my lack of understanding, but it appears that having -- > > enable-eh set during compilation of llvm-gcc is causing extra files > > to be compiled. > Oh, no. They are always compiled. > > > They do. However, it doesn't seem to stop it from failing during > > compilation of unwind-dw2.c for libgcc -- it has > > "__builtin_eh_return" in it. During 4-way FAT PPC compilation, it > > tries to compile this file and fails during the LowerOperation > > function. Turning --enable-eh off makes the error go away. > Could you please send me .bc, which fails? I'll try to figure out, what > is going wrong. >Here's the attached .ll file. Please use -march=ppc and/or ppc64. Thanks! -bw -------------- next part -------------- A non-text attachment was scrubbed... Name: unwind-dw2.s.gz Type: application/x-gzip Size: 19647 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070829/613939b3/attachment.bin>