[LLVMdev] Looking for advice on how to debug a problem with C++ style exception handling code that my compiler generates.

Sat Apr 11 15:33:00 PDT 2015

It appears that I've found a very curious effect where if I JIT a function that throws an exception and I use "call" to call it the throw fails despite there being a "catch" clause on the stack. But if I use “invoke” it works fine!

 If I call the function (@cc_invoke) that throws a “core::CatchThrow” exception like this:
call void @cc_invoke({ {}*, i64 }* %result-ptr, {}* %3, i64 2, {}* %4, {}* %5, {}* null, {}* null, {}* null)
;; Comment out the next two lines and   
;    to label %return0 unwind label %landing-pad1
;return0:
ret void

landing-pad1:                                     ; No predecessors!
  %6 = landingpad { i8*, i32 } personality i32 (...)* @__gxx_personality_v0
          cleanup
  resume { i8*, i32 } %6
}

It fails with: libc++abi.dylib: terminating with uncaught exception of type core::CatchThrow

If instead I convert the “call” into an “invoke” and hook in a dummy landing-pad like this:

invoke void @cc_invoke({ {}*, i64 }* %result-ptr, {}* %3, i64 2, {}* %4, {}* %5, {}* null, {}* null, {}* null)
    to label %return0 unwind label %landing-pad1
return0:
  ret void

landing-pad1:                                     ; No predecessors!
  %6 = landingpad { i8*, i32 } personality i32 (...)* @__gxx_personality_v0
          cleanup
  resume { i8*, i32 } %6
}

The CatchThrow exception is caught and everything works fine!  I don’t need to call the caller or any outer function with “invoke” except for in the function that has the landing pad that recognizes core::CatchThrow.

I don’t see anything in the Itanium ABI that says I need to call the function that throws an exception with “invoke” to get exception handling to work!

Does anyone have any ideas what I might be doing wrong?

On Apr 9, 2015, at 6:59 PM, Lang Hames <lhames at gmail.com> wrote:

> Hi Christian,
> 
> Andy's already covered the major points, but you could consider filing a bug at http://llvm.org/bugs too, especially if you've got a small test-case that demonstrates the issue. Exception handling hasn't been a priority in the past, but as more people adopt LLVM's JIT APIs I suspect it will get more attention, and bug reports will help us figure out what needs doing. 
> 
> Cheers,
> Lang.
> 
> On Thu, Apr 9, 2015 at 11:43 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote:
> Hi Christian,
> 
>  
> 
> I suspect that at least some of the details depend on what platform you’re working on.  I believe that MCJIT attempts to register eh frame information for either MachO or ELF objects (though for some ELF platforms nothing actually happens).  What happens to it after that is a darker area, at least for me.
> 
>  
> 
> Apparently there was a GDB command that did just what you want -- “info catch” -- but I had never used it and it has been removed.  It’s too bad because it sounds like a nice feature.  It was supposed to dump a list of catch handlers for whatever frame you’re looking at.  I suspect, however, that it would have just confirmed that your catch handler isn’t properly hooked up without being helpful in figuring out why.
> 
>  
> 
> You could try debugging the RuntimeDyld code that registers eh frames and see if that looks right.  RuntimeDyld::registerEHFrames() might be a helpful starting point.
> 
>  
> 
> -Andy
> 
>  
> 
>  
> 
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Christian Schafmeister
> Sent: Wednesday, April 08, 2015 10:09 PM
> To: LLVM Developers Mailing List
> Subject: [LLVMdev] Looking for advice on how to debug a problem with C++ style exception handling code that my compiler generates.
> 
>  
> 
>  
> 
> Hi,
> 
>  
> 
> I’m looking for advice on how to debug a problem with my exception handling code.  
> 
> I’m asking a specific question here - but general advice on how to debug something like this would be greatly appreciated.
> 
>  
> 
> Is there any way to get a list of landing pad clauses that are active at a particular point in a program?
> I'd like to get something like a backtrace but listing all active landing pad clauses. The typeids of the C++ types 
> I'm trying to debug a problem where an exception that I'm throwing is not being caught.   
> 
> I'm generating JITed code with LLVM and landing pads and I've got shared libraries - lots of things going on that could potentially be going wrong.
> 
>  
> 
> A list of the pointer values like @_ZTIN4core9DynamicGoE is what I’m looking for.  Then I could compare that to the typeids that I know should be in that list.
> 
>  
> 
> "(TRY-0).landing-pad":                            ; preds = %"(TRY-0).normal-dest14", %"(TRY-0).tagbody-B-1", %"(TRY-0).normal-dest10", %"(TRY-0).normal-dest9", %"(TRY-0).normal-dest8", %"(TRY-0).normal-dest", %"(TRY-0).tagbody-#:G1621-0"
> 
>   %14 = landingpad { i8*, i32 } personality i32 (...)* @__gxx_personality_v0
> 
>           catch i8* @_ZTIN4core9DynamicGoE
> 
>           catch i8* @_ZTIN4core10ReturnFromE, !dbg !26
> 
>   %15 = extractvalue { i8*, i32 } %14, 0, !dbg !26
> 
>   %16 = extractvalue { i8*, i32 } %14, 1, !dbg !26
> 
>   %17 = call i32 @llvm.eh.typeid.for(i8* @_ZTIN4core9DynamicGoE), !dbg !26
> 
>   %18 = icmp eq i32 %16, %17, !dbg !26
> 
>   br i1 %18, label %"(TRY-0).handler-block14470", label %"(TRY-0).dispatch-header19", !dbg !26
> 
>  
> 
> I’m getting this error when I throw a core::Unwind exception and I’m certain that there is a landing pad with that clause.
> 
>  
> 
> libc++abi.dylib: terminating with uncaught exception of type core::Unwind
> 
> ../../src/gctools/memoryManagement.cc:75 Trapped SIGABRT - starting debugger
> 
> ABORT was called!!!!!!!!!!!!
> 
>  
> 
>  
> 
> I’ve written a Common Lisp compiler that uses LLVM as the backend and it interoperates with C++ code and I use C++ exception handling for non-local exits.
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150411/0d53c3bc/attachment.html>