thr3ads.net - llvm dev - [LLVMdev] Looking for advice on how to debug a problem with C++ style exception handling code that my compiler generates. [Apr 2015]

If this information is useful, please help other people find it:
Share via:

Lang Hames

2015-Apr-09 22:59 UTC

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

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>

Christian Schafmeister

2015-Apr-11 22:33 UTC

head link

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

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>

Logan Chien

2015-Apr-12 00:15 UTC

head link

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

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

AFAICT, it is the design of LLVM IR and its implementation.  To catch the
exceptions thrown by the callee functions, we should use the invoke
instruction along with the landingpad instruction.  If you are calling a
function with a call instruction, the LLVM backend will simply assumes
frame unwinding when the callee throws an exception.


FYI, according to LLVM reference manual, an invoke-instruction
<http://llvm.org/docs/LangRef.html#invoke-instruction> has following
semantics:
> The ‘invoke‘ instruction causes control to transfer to a specified
> function, with the possibility of control flow transfer to either the ‘
> normal‘ label or the ‘exception‘ label. If the callee function returns
> with the “ret” instruction, control flow will return to the “normal”
> label. If the callee (or any indirect callees) returns via the “*resume*
> <http://llvm.org/docs/LangRef.html#i-resume>” instruction or other
> exception handling mechanism, control is interrupted and continued at the
> dynamically nearest “exception” label.
>OTOH, here's the description for call instruction
<http://llvm.org/docs/LangRef.html#call-instruction>:
> The ‘call‘ instruction represents a simple function call.
>
Hope this is helpful.

Best regards,
Logan

On Sun, Apr 12, 2015 at 6:33 AM, Christian Schafmeister <
chris.schaf at verizon.net> wrote:
>
> 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
<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.
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>
>
> _______________________________________________
> 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/20150412/d4209e10/attachment.html>

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

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

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

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