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

[Christian Schafmeister]

Dear Andrew,

Thank you very much.  A command like “info catch” would be very handy right now.

I put a breakpoint on RuntimeDyld::registerEHFrames and on entry the registers read as shown below.  It doesn’t matter if I compile the example with the old compiler (that generates code that works) or the new compiler (that generates code that terminates when the exception is thrown)   “rdx” == 0x0 in both cases.  So I don’t think that is the source of the problem.

I’m narrowing down on the problem by hacking my compiler to load a module from a bitcode file rather than generate a new module and systematically changing the new generated code into the old generated code.

On entry to RuntimeDyld::registerEHFrames
       rax = 0x00007f8518441c70
       rbx = 0x00007f8518441ba0
       rcx = 0x00007f8519923600
       rdx = 0x0000000000000000   <<<< argument 3  Size
       rdi = 0x00007f8518441bd8   <<<< argument 1  Addr
       rsi = 0xffffffffffffffff   <<<< argument 2  LoadAddr
       rbp = 0x00007fff5625e390
       rsp = 0x00007fff5625e2a8
        r8 = 0x00000000000003ff
        r9 = 0x00007f8519921600
       r10 = 0x00000001139d8000
       r11 = 0x0000000000000000
       r12 = 0x00007fff5625e2e0
       r13 = 0x00007f8518441bd8
       r14 = 0x00007f8518441c50
       r15 = 0x00007f8518441b10
       rip = 0x000000010b1c1bb0  clasp_boehm_o`llvm::RuntimeDyld::registerEHFrames()
    rflags = 0x0000000000000257
        cs = 0x000000000000002b
        fs = 0x0000000000000000
        gs = 0x0000000017da0000

void llvm::RTDyldMemoryManager::registerEHFrames	(	uint8_t * 	Addr, 
uint64_t 	LoadAddr, 
size_t 	Size 
)		[override, virtual]






On Apr 9, 2015, at 2:43 PM, 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.

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