Hello, Thomas> The problem apparently is the catch part.Catching is done by gcc unwinding runtime. Which is, in your case (--disable-shared), compiled by llvm and thus is definitely broken. What if you link the llvm-generated .S file with native g++ ?> writes data in section ".eh_frame", which sounds suspiciously like > exception handling info, which is not written by llvm. Is this expected > or is exception handling completely unimplemented on Linux/x86-64?Well, it's "expected, because unimplemented" :). The contents of ".eh_frame" section (aka EH common frame information) is among the missed stuff, I talked about. -- WBR, Anton Korobeynikov
> Catching is done by gcc unwinding runtime. Which is, in your case > (--disable-shared), compiled by llvm and thus is definitely broken. > What if you link the llvm-generated .S file with native g++ ?same behavior. The abort message changes (only the string, the meaning is identical), but otherwise the same. The exception is not caught and thus terminate -> abort is called.> Well, it's "expected, because unimplemented" :). The contents of > ".eh_frame" section (aka EH common frame information) is among the > missed stuff, I talked about.I see. Shouldn't there be an open bug about this? I had checked Bugzilla before posting here, but could not find anything. Could you perhaps point me more explicitly to the place where x86-64 support would have to be implemented? I searched around X86RegisterInfo.cpp a bit but I do not see why the 32bit mode should work and the 64bit mode not. Thomas
Reasonably Related Threads
- [LLVMdev] exception handling broken on x86-64?
- [LLVMdev] exception handling broken on x86-64?
- [LLVMdev] Unwind, exception handling, debuggers and profilers
- [LLVMdev] Unwind, exception handling, debuggers and profilers
- [LLVMdev] exception handling broken on x86-64?