Page MenuHomePhabricator

[lldb] Retrieve currently handled Obj-C exception via __cxa_current_exception_type and add GetCurrentExceptionBacktrace SB ABI
ClosedPublic

Authored by kubamracek on Mar 3 2018, 11:36 AM.

Details

Summary

This builds on https://reviews.llvm.org/D43884 and https://reviews.llvm.org/D43886 and extends LLDB support of Obj-C exceptions to also look for a "current exception" for a thread in the C++ exception handling runtime metadata (via call to __cxa_current_exception_type). We also construct an actual historical SBThread/ThreadSP that contains frames from the backtrace in the Obj-C exception object.

The high level goal this achieves is that when we're already crashed (because an unhandled exception occurred), we can still access the exception object and retrieve the backtrace from the throw point. In Obj-C, this is particularly useful because a catch+rethrow in very common and in those cases you currently don't have any access to the throw point backtrace.

Diff Detail

Repository
rL LLVM

Event Timeline

kubamracek created this revision.Mar 3 2018, 11:36 AM
kubamracek retitled this revision from [lldb] Retrieve currently handled Obj-C exception via __cxa_current_exception_type to [lldb] Retrieve currently handled Obj-C exception via __cxa_current_exception_type and add GetCurrentExceptionBacktrace SB ABI.Nov 29 2018, 2:21 PM
kubamracek edited the summary of this revision. (Show Details)

This looks good. Can you add two more tests:

  1. Can you add a step to your tests that shows fetching the current exception object from a thread that doesn't have an exception does the right thing (i.e. nothing).
  2. Since C++ and ObjC exceptions use the same mechanism can you test that at abort after an uncaught C++ exception, getting the exception for the thread also does nothing (i.e. doesn't crash or produce some mangled object).

Addressing comment 1 (checking that GetCurrentException and GetCurrentExceptionBacktrace returns nothing when there's no exception in flights). Will address comment 2 in a bit.

Addressed comment 2. Changed the test to use an Obj-C++ source file, and added a case that throws a plain C++ exception.

jingham accepted this revision.Dec 19 2018, 5:49 PM

That's great. There are a couple places where you use self.assertEqual(..., False) where you can use self.assertFalse if you want. A very minor point...

packages/Python/lldbsuite/test/lang/objc/exceptions/TestObjCExceptions.py
47 ↗(On Diff #178991)

You can also say self.assertFalse here if you want. Not very important.

193 ↗(On Diff #178991)

Since you use assertTrue above, it would be more symmetrical to use self.assertFalse here?

This revision is now accepted and ready to land.Dec 19 2018, 5:49 PM
This revision was automatically updated to reflect the committed changes.

Thanks for the review! Switched to self.assertFalse and self.assertTrue and landed in r349718.