exception aborts the program on x86-32 when a program refers to an external function

[Pekka Jääskeläinen]

This is the expected error message from tcecc when the program has a function call to an undefined function:

../../../../src/base/program/Program.cc:1209 'procedure with symbol: do_something not found!'

However, when running with 32bit x86 the exception that finally is caught in LLVMTCE.cc is not propagated but causes a program abort: terminate called after throwing an instance of 'InstanceNotFound'

This must have something to do with exception handling in LLVM. IIRC LLVM doesn't use exceptions and maybe it disables them completely and this TCE code linked with such a library then fails when trying to propagate an exception through the LLVM libs.

The backtrace:

Program received signal SIGABRT, Aborted.
0x0012d422 in __kernel_vsyscall ()
(gdb) bt
#0 0x0012d422 in __kernel_vsyscall ()
#1 0x02fb7651 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0x02fbaa82 in *__GI_abort () at abort.c:92
#3 0x02f1152f in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/libstdc++.so.6
#4 0x02f0f465 in ?? () from /usr/lib/libstdc++.so.6
#5 0x02f0f4a2 in std::terminate() () from /usr/lib/libstdc++.so.6
#6 0x02f0f5e1 in __cxa_throw () from /usr/lib/libstdc++.so.6
#7 0x025fdf0c in TTAProgram::Program::convertSymbolRef (this=0x80b38a8, tsr=...) at Program.cc:1211
#8 0x025fed59 in TTAProgram::Program::convertSymbolRefsToInsRefs (this=0x80b38a8) at Program.cc:1236
#9 0x02b4eaca in llvm::LLVMTCEIRBuilder::doFinalization (this=0x80a9ef0, m=...) at LLVMTCEIRBuilder.cc:715
#10 0x017a77ae in llvm::FPPassManager::doFinalization (this=0x8092b00, M=...) at PassManager.cpp:1552
#11 0x017afe45 in llvm::FPPassManager::runOnModule (this=0x8092b00, M=...) at PassManager.cpp:1536
#12 0x017af901 in llvm::MPPassManager::runOnModule (this=0x8089bd8, M=...) at PassManager.cpp:1588
#13 0x017afa3a in llvm::PassManagerImpl::run (this=0x8089a30, M=...) at PassManager.cpp:1672
#14 0x017afb30 in llvm::PassManager::run (this=0xbfffea08, M=...) at PassManager.cpp:1716
#15 0x02af4b62 in LLVMBackend::compile (this=0xbfffed1c, module=..., emulationModule=0x80a2ca8, plugin=..., target=..., optLevel=3, ipData=0x807eff8) at LLVMBackend.cc:528
#16 0x02af3b47 in LLVMBackend::compile (this=0xbfffed1c, bytecodeFile=..., emulationBytecodeFile=..., target=..., optLevel=3, debug=false, ipData=0x807eff8) at LLVMBackend.cc:334
#17 0x0804ad44 in main (argc=13, argv=0xbfffeec4) at LLVMTCE.cc:176

[Vladimir Guzma (vladimir-guzma)]

If you can produce input file that triggers exception, I can try on Mac OSX if the OS makes any difference in output.
With 32 and 64bit builds of tools.

[Pekka Jääskeläinen (pekka-jaaskelainen)]

It might not be strictly a 32bit vs. 64bit issue, but just a matter of luck...

Every code like this reproduces it:

#include <stdint.h>

void do_something();

int main() {
   do_something();
   return 0;
}

However, by googling around (*) on this issue it becomes clear that throwing exceptions across shared library boundaries is risky and fragile. So in this case we should do what Kultala suggested in IRC: print an error to std::cerr where this is detected and exit(2). Not throw and assume the CLI code is able to catch it through several layers of different plugins/shared libs.

(*)
http://www.qtcentre.org/threads/4726-exception-in-shared-libraries
http://old.nabble.com/-static-libgcc,-static-libstdc%2B%2B.a-and-dynamicly-loaded-so-files-td26745112.html
http://stackoverflow.com/questions/5044993/typeinfo-shared-libraries-and-dlopen-without-rtld-global

[Pekka Jääskeläinen (pekka-jaaskelainen)]

Now fails gracefully both on x86 and x86-64 with

"Error: procedure 'do_something' not found!"