Hello Evan and Dale,
Shootout-C++/except works for me. Anton suggests there may be an
issue with the unwinding libraries and he may be right, I'll look at
it with you tomorrow.
Yes. Please be sure, that you're linking with system libgcc.{so,dylib},
not with llvm-compiled one.
Did anything ever come of the work on exception handling for x86_64?
I'm having problems with exceptions on linux x86_64. Today, on x86_64 with a recently updated working copy of llvm, I tried calling a JITted function that calls an external function that throws:
thrower.cpp: (which gets compiled into a dynamic library)
extern "C"
void throwexception()
{
throw 5;
}
My code that invokes the JIT:
llvm::Function *q_main = implementationVisitor.m_module- >getFunction("q_main");
std::vector<GenericValue> args;
try {
GenericValue GV=EE->runFunction(q_main, args);
} catch (...) {
printf("hello!\n");
}
}
And instead of printing out hello I got
Program received signal SIGABRT, Aborted.
[Switching to Thread 48011952506048 (LWP 6197)]
0x00002baaa72d1765 in raise () from /lib/libc.so.6
(gdb) where
#0 0x00002baaa72d1765 in raise () from /lib/libc.so.6
#1 0x00002baaa72d31c0 in abort () from /lib/libc.so.6
#2 0x00002baaa6bcb7b4 in __gnu_cxx::__verbose_terminate_handler () from /usr/lib/libstdc++.so.6
#3 0x00002baaa6bc9746 in ?? () from /usr/lib/libstdc++.so.6
#4 0x00002baaa6bc9773 in std::terminate () from /usr/lib/libstdc++.so.6
#5 0x00002baaa6bc985a in __cxa_throw () from /usr/lib/libstdc++.so.6
#6 0x00002baaa69046b7 in throwexception () from /usr/local/src/GQ/libthrower.so
#7 0x00002baaa777f06d in ?? ()
#8 0x34353530372e302d in ?? ()
#9 0x0000000000000030 in ?? ()
#10 0x000000000051d7b4 in llvmImplementationVisitorTest () at main.cpp:365
#11 0x000000000051e06c in main (argc=1, argv=0x7fff047e0298) at main.cpp:389
Am I doing anything wrong?
q_main looks like this:
After pass manager:
; ModuleID = 'Q'
define void @q_main() {
entry:
call void @throwexception( )
ret void
}
declare void @throwexception()
declare void @abort()
Did anything ever come of the work on exception handling for x86_64?
I'm having problems with exceptions on linux x86_64.
I'm fairly sure that exception handling doesn't currently work on
x86-64 linux (it may work with darwin - not sure). I don't know
what it would take to get it to work.
Ciao,
Duncan.
On Darwin, the Dwarf metadata emitted in .s/.o files is correct (although there may be bugs, it hasn't been exercised beyond the llvm and gcc testsuites). The unwinding code in libgcc* has not been ported to x86-64 and does not work. Thus, if you take the libgcc* from a non-llvm gcc and link llvm-gcc-produced .o files with that, things work.
It would probably not take much to get Linux x86-64 to this state, I doubt the metadata is much different from Darwin.
I'm sorry to beat a dead horse, but I just want to be clear that I'm asking about exception handling from within the JIT, not the native code produced by llvm-g++. For example, the following doesn't work for me on linux x86 (let alone x86_64). I'm using an llvm build from revision 48493 (March 18th).
exceptiontest.cpp:
#include <stdio.h>
int main(int argc, char *argv)
{
try {
throw 5;
} catch (int i) {
printf("caught %d\n", i);
}
return 0;
}
$ llvm-g++ -emit-llvm exceptiontest.cpp -c
$ lli -enable-eh -enable-correct-eh-support exceptiontest.o
terminate called after throwing an instance of 'int'
lli(_ZN40_GLOBAL__N_Signals.cpp_00000000_17C8705F15PrintStackTraceEv+0x24)[0x884948c]
lli(_ZN40_GLOBAL__N_Signals.cpp_00000000_17C8705F13SignalHandlerEi+0x115)[0x8849623]
[0xffffe420]
/lib/tls/libc.so.6(abort+0xeb)[0x4018fdbb]
/usr/lib/libstdc++.so.6(_ZN9__gnu_cxx27__verbose_terminate_handlerEv+0x179)[0x4010b489]
/usr/lib/libstdc++.so.6[0x40108e15]
/usr/lib/libstdc++.so.6[0x40108e52]
/usr/lib/libstdc++.so.6[0x40108fba]
[0x40307055]
lli(_ZN4llvm15ExecutionEngine17runFunctionAsMainEPNS_8FunctionERKSt6vectorISsSaISsEEPKPKc+0x41c)[0x84f7428]
lli(main+0x44b)[0x83b66d3]
/lib/tls/libc.so.6(__libc_start_main+0xd0)[0x4017bea0]
lli[0x83b61c1]
Aborted
I had hoped this would work --- and if I use llvm-g++ to compile exceptiontest.cpp to native code it does. But it looks like the JIT is producing stack frames that the C++ runtime doesn't like.
Robert