similar to: [LLVMdev] Questions about exceptions

Interestingly, I also get a similar error in a different executable (my unittest): pure virtual method called terminate called without an active exception 0 tartc 0x00000001010a8265 PrintStackTrace(void*) + 53 1 tartc 0x00000001010a88cc SignalHandler(int) + 364 2 libSystem.B.dylib 0x00007fff831341ba _sigtramp + 26 3 libSystem.B.dylib 0x7261742e65637365 _sigtramp +

On Sat, Oct 15, 2011 at 9:49 PM, Chandler Carruth <chandlerc at google.com>wrote: > On Sat, Oct 15, 2011 at 9:20 PM, Talin <viridia at gmail.com> wrote: > >> I recently updated my version of LLVM from revision 140108 to 142082, and >> several things broke, most of which were easily fixed. However, I'm now >> getting a "pure virtual method called"

Hi Talin, I have some questions below. If these topics have already been discussed in earlier threads, kindly point me there. I'm aware of your GC proposal, but the rest is new to me. On Jul 1, 2011, at 11:05 AM, Talin wrote: > Garbage collection is still way too difficult. The biggest problem is the inability to track SSA values - it requires the frontend to generate very inefficient and

On Wed, Nov 11, 2009 at 11:11 AM, Chris Lattner <clattner at apple.com> wrote: > On Nov 10, 2009, at 4:10 PM, Talin wrote: > > I realize that most users of LLVM aren't affected by this, because most > frontends aren't target-neutral, and thus know in advance how big a pointer > is. At least, that's my impression. > > I believe that. > > >

I've been struggling for several days, trying to get native exceptions to work in my code. I managed to boil down the IR to the simplest possible example that I can think of. If anyone on this list can tell me what changes I need to make to the following code to get it to work (i.e. return 0 instead of a bus error), it would make my life immensely better. ; ModuleID =

Hi Talin, You're not using the llvm intrinsics for exception handling, so your code won't work. Using _Unwind_RaiseException should be OK, but your main function must at least use llvm.eh.exception, llvm.eh.selector.i32/64 and probably __cxa_begin_catch and __cxa_end_catch. Nicolas Talin wrote: > I've been struggling for several days, trying to get native exceptions > to

Talin wrote: > Nicolas Geoffray wrote: >> Hi Talin, >> >> You're not using the llvm intrinsics for exception handling, so your >> code won't work. Using _Unwind_RaiseException should be OK, but your >> main function must at least use llvm.eh.exception, >> llvm.eh.selector.i32/64 and probably __cxa_begin_catch and __cxa_end_catch. >> >

Well, after much labor, I think I have managed to create a personality function that works. But I must say it is frightening how complicated all of this stuff is. -- Talin Duncan Sands wrote: > Hi Talin, if you change @throwSomething so that it prints a message > if the _Unwind_RaiseException call returns, then you will see that > it does in fact return. > > define internal

Duncan Sands wrote: > I would just use the C personality function, __gcc_personality_v0, if > I were you. It should know where to jump to because the code generators > record the invoke unwind target in the dwarf exception handling info in > the object file. > > So I tried what you suggested, and it just gives me a bus error: define i32 @main(i32, i8**) nounwind {

On Thu, Nov 12, 2009 at 5:58 PM, Chris Lattner <clattner at apple.com> wrote: > On Nov 12, 2009, at 11:29 AM, Talin wrote: > > > Well, as far as intp goes (or iptr if you prefer - the naming convention in > LLVM is i<size>) > > > How about "intptr". > > here's what I would expect: > > - General rule #1: If an instruction accepts

Nicolas Geoffray wrote: > Hi Talin, > > You're not using the llvm intrinsics for exception handling, so your > code won't work. Using _Unwind_RaiseException should be OK, but your > main function must at least use llvm.eh.exception, > llvm.eh.selector.i32/64 and probably __cxa_begin_catch and __cxa_end_catch. > Let me ask a follow-up question then - if the

Hello, Talin > By using the llvm.eh* intrinsics, I have managed to get the code to call > my custom personality function without crashing. However, what I don't > yet understand is how to get the result from the personality function > back to the landing pad. You might find this useful: http://www.codesourcery.com/public/cxx-abi/abi-eh.html#cxx-catch -- With best regards, Anton

I have a problem where my LLVM-generated code works on Linux but not on OS X, and the problem involves non_lazy_ptr. I have an external symbol named "@gc_safepoint_map", which is generated by the linker's GCStrategy plugin. Since it is not generated until link time, I declared it as an external symbol so that the modules that use it can compile without error. Here's what the

After working with LLVM for several years now, one problem that remains unsolved is how to generate a stack backtrace for exceptions. My basic approach is simple: I have two different exception personality functions, a "lightweight" one that just does the bare minimum needed to handle exception, and a "capturing" one that (ideally) records the call frame information as it

Howdy, We believe we've found a bug in the libgcc or libstdc++ library (not sure which one) packaged with the gcc43 port in fbsd7 on an Intel x86-64. A program linked against those libraries aborts when an exception is thrown. It does not abort if -lpthread is added to the link line, even though the program does not use threads. I believe the problem is related to the pthread stubs in

On Tue, May 19, 2009 at 9:45 AM, Nicolas Geoffray <nicolas.geoffray at lip6.fr> wrote: > Talin wrote: >> I see. OK, I will try that. >> >> I was hoping to be able to test the exception type in the personality >> function - the language I am working on has its own type system, >> unrelated to C or C++, so I want to minimize reliance on C++ exception >>

I hate to be a nag, but after several days of working on this I am still utterly stumped. Let me recap the situation as it currently stands: I'm trying to write code that generates DWARF debugging information for my compiler using DIFactory and friends. Unfortunately the information I am generating appears to be invalid, but I can't figure out the cause. Based on the advice in the

Hi Talin, I think that the framework for GC assumes llvm.gcroot to be in the first block. If it is not the case in your example, it will break these assumptions. Nicolas On Sun, Sep 26, 2010 at 1:38 AM, Talin <viridia at gmail.com> wrote: > I'm working on the code to handle GC tracing of "intermediate values" (as > described in the GC doc), and I've run into a

Talin wrote: > I see. OK, I will try that. > > I was hoping to be able to test the exception type in the personality > function - the language I am working on has its own type system, > unrelated to C or C++, so I want to minimize reliance on C++ exception > handling libraries. In this case, I guess I can do the exception type > checking in the landing pad instead of the

Hi Talin, On Fri, Feb 18, 2011 at 1:36 AM, Talin <viridia at gmail.com> wrote: > > Thinking about it even more, here's a short summary of what I would > propose: > > - *llvm.gc.value*(value, metadata) - marks an SSA value as a garbage > collection root. This remains in effect for the lifetime of the SSA value. > - *llvm.gc.declare*(alloca, metadata) - marks