llvm dev - Apr 2015 - [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/33dfb3f0/attachment.html>

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>

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>

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>