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

[Kaylor, Andrew]

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<http://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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150409/3aa5baad/attachment.html>