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

[Lang Hames]

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/20150409/8de5858a/attachment.html>