similar to: [LLVMdev] exception handling broken on x86-64?

Hello, Thomas > when building the second release candidate of llvm 2.2 I noticed that > exception handling seems to be broken on Linux x86-64. The exception EH never worked on x86-64. Mainly due to absence of intrinsics used in unwinding runtime. Also, some other important stuff is missed as well (like stack layout information). > When compiled with llvm-g++ it aborts after printing

Hello, Thomas > > I'd suggest to start with filling necessary bits in the > > X86RegisterInfo.cpp. This includes frame moves information and > > description of stack layout. > I looked at X86RegisterInfo.cpp, but I think that it already supports > x86-64. At least there were no obvious places were the code would only > work for 32bit mode. Right. See my last e-mail

Folks, I'm sorry for getting at this again, but this will not be the last discussion on the topic, so let's just get to business. We're about to merge the last critical patch to make EHABI compatible with other EH mechanisms in LLVM (D3079), and that has unearthed a few issues with the function attributes. Logan's blog post [1] contains a proposal to split unwinding from

On 20 March 2014 02:09, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > I think this is just 2. It uses .eh_frame for unwinding proper. The > only difference in .eh_frame is that there is a personality function > defined. If there is no debug information, it should still be possible to unwind the stack via the saved LR on the stack, no? If there is only line info, you

Dale, > Works for me on x86-64 Darwin, fwiw. That looks pretty strange. Ok, it can work for small testcases, but will surely fail when you try to use for something more real. Currently it at least lacks information about frame moves. So, every invoke, which needs to restore call-clobbered registers during unwinding will be broken. Does Shootout-C++/except work for you? And stuff from llvm

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. -- WBR, Anton Korobeynikov

On Feb 9, 2008, at 6:53 AM, Thomas Neumann wrote: > Hi, > > when building the second release candidate of llvm 2.2 I noticed that > exception handling seems to be broken on Linux x86-64. The exception > is > thrown but never caught. > This can be seen by this trivial example: > > #include <iostream> > using namespace std; > class A { }; > int main()

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

Hi, when building the second release candidate of llvm 2.2 I noticed that exception handling seems to be broken on Linux x86-64. The exception is thrown but never caught. This can be seen by this trivial example: #include <iostream> using namespace std; class A { }; int main() { cout << "A" << endl; try { cout << "B" << endl;

Hello, Robert > 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. Yes, surely. Emission of frames 'on fly' won't automatically make them visible for the unwinding runtime. JIT currently doesn't register these frames

Hi, I'm trying to learn all that I can about exception handling from the compiler's point of view. Although much has been written about compiler theory in general -- parsing, code generation, you name it -- I can find almost nothing on the specific problem of exception handling support. In fact, the most informative document I've been able to find so far is "Bill's

While comparing debug info between GCC and Clang I found a section that only Clang produces and GCC never produces: debug_frame. It seems (though I haven't verified this with absolute certainty) as though GCC just always uses eh_frame. LLVM on the other hand sometimes uses eh_frame and sometimes uses debug_frame. Here's an example: int f1(); int i = f1(); void func() { } Compiled with

Where we are on the subject... Are we sure EH is done for x86? These two tests have never worked on Mac OS X / x86: SPEC/CINT2006/471.omnetpp Shootout-C++/except Evan On Feb 9, 2008, at 2:57 PM, Dale Johannesen wrote: > > On Feb 9, 2008, at 2:48 PM, Anton Korobeynikov wrote: >>> After comparing the generated assembler code with native gcc code I >>> think the generated

On Feb 9, 2008, at 11:20 AM, Anton Korobeynikov wrote: > Dale, > >> Works for me on x86-64 Darwin, fwiw. > That looks pretty strange. Ok, it can work for small testcases, but > will > surely fail when you try to use for something more real. Currently > it at > least lacks information about frame moves. So, every invoke, which > needs > to restore

On Feb 9, 2008, at 2:48 PM, Anton Korobeynikov wrote: >> After comparing the generated assembler code with native gcc code I >> think the generated code is fine, just the exception handler info in >> the non-code sections is broken/missing. > It seems, that EH dwarf information emission is disabled in > X86TargetAsmInfo.cpp. Remove the is64Bit() condition near >

>Keeping .eh_frame separated should still simplifies the linker because >until the last step of building .eh_frame and .eh_frame_hdr, we don't >really need to parse .eh_frame sections. So, if we have separate .eh_frame >sections on -ffunction-sections, all we have to do is (1) garbage-collect >sections and (2) construct .eh_frame and .eh_frame_hdr sections from live

Hi, Many linkers including lld have a feature to eliminate unused sections from output to make output smaller (which is essentially a mark-sweep gc where sections are vertices and relocations are edges). lld and GNU gold have yet another feature, ICF, to merge functions by contents to save more space. When we remove or merge a function, we want to eliminate its exception handling information as

Hi, There will be problems with eh_frame_hdr. Eh_frame_hdr is needed to use the binary search instead of the linear search. Having eh_frame per a function will cause no eh_frame_hdr or multiple eh_frame_hdr and will degrade search from binary to linear. As we create eh_frame_hdr in most cases there is no problem to filter out garbage eh_frame sections. If there is information about unused

> But if we still need to deal with CIEs and generate .eh_frame_hdr in a special way, > does it make sense to make this change to simplify only a small part of a linker? For huge C++ projects this could improve link time if GC is a bottleneck. It will also improve eh_frame_hdr build time because you don’t spend time on parsing garbage. However a linker will have to have two versions of GC:

Hi all, I'm toying around with LLVM's GC support and am struggling with the following. I have a little test snippet (a .ll file with IR) that uses llvm.gcroot to mark a GC root, but when I compile it to assembly with llc, followed by generating an executable with gcc I get an error related to exception handling: 22:40|melis at juggle2:~/projects/llvm_gc> cat root.ll %obj = type { i8*,