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:

Logan Chien

2015-Apr-12 03:03 UTC

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

Hi Christian,

Thanks for your explanation.  I know your situation now.  I would suggest
you to check the optimization pass used by the JIT compiler, especially
IPO/PruneEH.cpp.  It will try to add nounwind attribute to functions which
will result in the problem you have mentioned earlier.

Alternatively, as a workaround, try to add uwtable (function attribute) to
the functions that are generated by your compiler.  This may help as well.

Sincerely,
Logan

On Sun, Apr 12, 2015 at 8:49 AM, Christian Schafmeister <
chris.schaf at verizon.net> wrote:
> Logan,
>
> There may be some confusion here because I wasn’t completely clear about
> what was calling what and where “invoke” appeared to be necessary when I
> JIT the code and where I realize that “invoke” is absolutely necessary.
>  As far as I understand the Itanium ABI I only need an “invoke” in function
> A when function B is invoked - the rest of the calls to C() and D() should
> be able to use “call".
>
>
> Here’s an example in C++ (for illustration) and then the identical example
> in Common Lisp.
>
> In Common Lisp I can compile individual expressions in the REPL.
> Here is a more illustrative example.   If I compile all of these functions
> ahead of time - everything works fine and D() and C() are called using LLVM
> “call”.
> But if I JIT these functions one at a time it will fail.  If I use llvm
> “invoke” to JIT the function C() - then the thrown exception will make it
> to A() and everything works.
>
> // In C++
> //
> void D() {
>     throw MyException();
> };
>
> void C() {
>     D();    // This should be able to be called with “call”
> // - but if I JIT this function it won’t work - I need “invoke” and a
> dummy landing pad
> };
>
> void B() {
>     C();    // This can be called with "call"
> };
>
>
> void A() {
>     try {
>         B();     // <<--- This needs to be called with
"invoke"
>     } catch ( MyException& e) {
> /* Do something */
>     };
> };
>
>
> In Common Lisp:
>
> (defun d ()
>  (throw 'Exception nil))
>
> (defun c ()
>   (d))    ; <-- This can be called with llvm “call” but if I JIT this
> function it will fail!  I need to use “invoke”!
>
> (defun b ()
>   (c))    ; <-- This can be called with llvm "call"
>
> (defun a ()
>   (catch 'exception
>     (b)))   ; <-- This needs to called with llvm “invoke"
>
>
>
> On Apr 11, 2015, at 8:15 PM, Logan Chien <tzuhsiang.chien at
gmail.com>
> wrote:
>
> Hi Christian,
>
> > 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!
>
> 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/b0ee04b0/attachment.html>

Christian Schafmeister

2015-Apr-12 04:51 UTC

head link

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

Logan,

Thank you very much for the feedback and guidance.

The passes that I use for JIT compilation are as follows - I don’t see prune-eh
in there - could it still be happening?

(defun create-function-pass-manager-for-compile (module)
  (let ((fpm (llvm-sys:make-function-pass-manager module)))
    (llvm-sys:function-pass-manager-add fpm
(llvm-sys:create-basic-alias-analysis-pass))   ;; <<< passes start here
    (llvm-sys:function-pass-manager-add fpm
(llvm-sys:create-instruction-combining-pass))
    (llvm-sys:function-pass-manager-add fpm
(llvm-sys:create-promote-memory-to-register-pass))
    (llvm-sys:function-pass-manager-add fpm (llvm-sys:create-reassociate-pass))
    (llvm-sys:function-pass-manager-add fpm (llvm-sys:create-gvnpass nil))
    (llvm-sys:function-pass-manager-add fpm
(llvm-sys:create-cfgsimplification-pass -1))
    (llvm-sys:do-initialization fpm)
    fpm))

I set things up to add the “uwtable” function attribute to every function that I
generate - a current module looks like this: 
https://gist.github.com/drmeister/107a84d3d5023ebf13a8
On line 617 is the function (now it has the "uwtable" attribute) that
is not propagating an exception thrown in cc_call on line 642.

A couple of questions:  the prototype for cc_call on line 559 has the function
attribute “nounwind” - I should probably remove that - correct?

When I load the bitcode file for this module and then dump it just before it is
JITted, the “uwtable” attribute has disappeared - is this prune-eh doing its
work even though it’s not listed above in the list of function pass managers?

I feel like there may be multiple things going on, thwarting my attempts to get
these functions to propagate an exception.

Thanks,

.Chris.


On Apr 11, 2015, at 11:03 PM, Logan Chien <tzuhsiang.chien at gmail.com>
wrote:
> Hi Christian,
> 
> Thanks for your explanation.  I know your situation now.  I would suggest
you to check the optimization pass used by the JIT compiler, especially
IPO/PruneEH.cpp.  It will try to add nounwind attribute to functions which will
result in the problem you have mentioned earlier.
> 
> Alternatively, as a workaround, try to add uwtable (function attribute) to
the functions that are generated by your compiler.  This may help as well.
> 
> Sincerely,
> Logan
> 
> On Sun, Apr 12, 2015 at 8:49 AM, Christian Schafmeister <chris.schaf at
verizon.net> wrote:
> Logan,
> 
> There may be some confusion here because I wasn’t completely clear about
what was calling what and where “invoke” appeared to be necessary when I JIT the
code and where I realize that “invoke” is absolutely necessary.    As far as I
understand the Itanium ABI I only need an “invoke” in function A when function B
is invoked - the rest of the calls to C() and D() should be able to use
“call".
> 
> 
> Here’s an example in C++ (for illustration) and then the identical example
in Common Lisp.
> 
> In Common Lisp I can compile individual expressions in the REPL.  
> Here is a more illustrative example.   If I compile all of these functions
ahead of time - everything works fine and D() and C() are called using LLVM
“call”.
> But if I JIT these functions one at a time it will fail.  If I use llvm
“invoke” to JIT the function C() - then the thrown exception will make it to A()
and everything works.
> 
> // In C++
> //
> void D() {
>     throw MyException();
> };
> 
> void C() {
>     D();    // This should be able to be called with “call” 
> 		// - but if I JIT this function it won’t work - I need “invoke” and a
dummy landing pad
> };
> 
> void B() {
>     C();    // This can be called with "call"
> };
> 
> 
> void A() {
>     try {
>         B();     // <<--- This needs to be called with
"invoke"
>     } catch ( MyException& e) {
> 	/* Do something */
>     };
> };
> 
> 
> In Common Lisp:
> 
> (defun d ()
>  (throw 'Exception nil))
> 
> (defun c ()
>   (d))    ; <-- This can be called with llvm “call” but if I JIT this
function it will fail!  I need to use “invoke”!
> 
> (defun b ()
>   (c))    ; <-- This can be called with llvm "call"
> 
> (defun a ()
>   (catch 'exception
>     (b)))   ; <-- This needs to called with llvm “invoke"
> 
> 
> 
> On Apr 11, 2015, at 8:15 PM, Logan Chien <tzuhsiang.chien at
gmail.com> wrote:
> 
>> Hi Christian,
>> 
>> > 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!
>> 
>> 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 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” 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: 
>> 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: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/9d8d1bf0/attachment.html>

Christian Schafmeister

2015-Apr-12 04:58 UTC

head link

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

Logan,

I need to make a correction of the post that preceded this one!

I was wrong when I said this:> When I load the bitcode file for this module and then dump it just before
it is JITted, the “uwtable” attribute has disappeared - is this prune-eh doing
its work even though it’s not listed above in the list of function pass
managers?
The “uwtable” attribute does not disappear!   I had forgotten to llvm-as the .ll
file that I was hand-editing. (I’ve hacked my compiler so that it JITs a module
from a bitcode file that I hand edit while I’m trying to sort out whether these
attributes can be properly set to avoid the problem that I’m seeing).

I’m trying different combinations of function attributes to see if that fixes
the problem.

Best,

.Chris.

On Apr 12, 2015, at 12:51 AM, Christian Schafmeister <chris.schaf at
verizon.net> wrote:
> Logan,
> 
> Thank you very much for the feedback and guidance.
> 
> The passes that I use for JIT compilation are as follows - I don’t see
prune-eh in there - could it still be happening?
> 
> (defun create-function-pass-manager-for-compile (module)
>   (let ((fpm (llvm-sys:make-function-pass-manager module)))
>     (llvm-sys:function-pass-manager-add fpm
(llvm-sys:create-basic-alias-analysis-pass))   ;; <<< passes start here
>     (llvm-sys:function-pass-manager-add fpm
(llvm-sys:create-instruction-combining-pass))
>     (llvm-sys:function-pass-manager-add fpm
(llvm-sys:create-promote-memory-to-register-pass))
>     (llvm-sys:function-pass-manager-add fpm
(llvm-sys:create-reassociate-pass))
>     (llvm-sys:function-pass-manager-add fpm (llvm-sys:create-gvnpass nil))
>     (llvm-sys:function-pass-manager-add fpm
(llvm-sys:create-cfgsimplification-pass -1))
>     (llvm-sys:do-initialization fpm)
>     fpm))
> 
> I set things up to add the “uwtable” function attribute to every function
that I generate - a current module looks like this: 
https://gist.github.com/drmeister/107a84d3d5023ebf13a8
> On line 617 is the function (now it has the "uwtable" attribute)
that is not propagating an exception thrown in cc_call on line 642.
> 
> A couple of questions:  the prototype for cc_call on line 559 has the
function attribute “nounwind” - I should probably remove that - correct?
> 
> When I load the bitcode file for this module and then dump it just before
it is JITted, the “uwtable” attribute has disappeared - is this prune-eh doing
its work even though it’s not listed above in the list of function pass
managers?
> 
> I feel like there may be multiple things going on, thwarting my attempts to
get these functions to propagate an exception.
> 
> Thanks,
> 
> .Chris.
> 
> 
> On Apr 11, 2015, at 11:03 PM, Logan Chien <tzuhsiang.chien at
gmail.com> wrote:
> 
>> Hi Christian,
>> 
>> Thanks for your explanation.  I know your situation now.  I would
suggest you to check the optimization pass used by the JIT compiler, especially
IPO/PruneEH.cpp.  It will try to add nounwind attribute to functions which will
result in the problem you have mentioned earlier.
>> 
>> Alternatively, as a workaround, try to add uwtable (function attribute)
to the functions that are generated by your compiler.  This may help as well.
>> 
>> Sincerely,
>> Logan
>> 
>> On Sun, Apr 12, 2015 at 8:49 AM, Christian Schafmeister <chris.schaf
at verizon.net> wrote:
>> Logan,
>> 
>> There may be some confusion here because I wasn’t completely clear
about what was calling what and where “invoke” appeared to be necessary when I
JIT the code and where I realize that “invoke” is absolutely necessary.    As
far as I understand the Itanium ABI I only need an “invoke” in function A when
function B is invoked - the rest of the calls to C() and D() should be able to
use “call".
>> 
>> 
>> Here’s an example in C++ (for illustration) and then the identical
example in Common Lisp.
>> 
>> In Common Lisp I can compile individual expressions in the REPL.  
>> Here is a more illustrative example.   If I compile all of these
functions ahead of time - everything works fine and D() and C() are called using
LLVM “call”.
>> But if I JIT these functions one at a time it will fail.  If I use llvm
“invoke” to JIT the function C() - then the thrown exception will make it to A()
and everything works.
>> 
>> // In C++
>> //
>> void D() {
>>     throw MyException();
>> };
>> 
>> void C() {
>>     D();    // This should be able to be called with “call” 
>> 		// - but if I JIT this function it won’t work - I need “invoke” and a
dummy landing pad
>> };
>> 
>> void B() {
>>     C();    // This can be called with "call"
>> };
>> 
>> 
>> void A() {
>>     try {
>>         B();     // <<--- This needs to be called with
"invoke"
>>     } catch ( MyException& e) {
>> 	/* Do something */
>>     };
>> };
>> 
>> 
>> In Common Lisp:
>> 
>> (defun d ()
>>  (throw 'Exception nil))
>> 
>> (defun c ()
>>   (d))    ; <-- This can be called with llvm “call” but if I JIT
this function it will fail!  I need to use “invoke”!
>> 
>> (defun b ()
>>   (c))    ; <-- This can be called with llvm "call"
>> 
>> (defun a ()
>>   (catch 'exception
>>     (b)))   ; <-- This needs to called with llvm “invoke"
>> 
>> 
>> 
>> On Apr 11, 2015, at 8:15 PM, Logan Chien <tzuhsiang.chien at
gmail.com> wrote:
>> 
>>> Hi Christian,
>>> 
>>> > 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!
>>> 
>>> 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 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” 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: 
>>> 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: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/36aba58c/attachment.html>

Reasonably Related Threads

Search for more possibly parallel threads

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.

Reasonably Related Threads