This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Extract more fields from NSException values
ClosedPublic

Authored by kubamracek on Feb 28 2018, 10:34 AM.

Details

Summary

This patch teaches LLDB about more fields on NSException Obj-C objects, specifically we can now retrieve the "name" and "reason" of an NSException. The goal is to eventually be able to have SB API that can provide details about the currently thrown/caught/processed exception.

Diff Detail

Repository
rLLDB LLDB

Event Timeline

kubamracek created this revision.Feb 28 2018, 10:34 AM
davide added a subscriber: davide.Feb 28 2018, 7:45 PM

I like the way this patch is structured, some comments inline.

packages/Python/lldbsuite/test/lang/objc/exceptions/TestObjCExceptions.py
2–5

This looks like it doesn't need any interactivity whatsoever, so you can probably convert this to a lit test. See the examples in lit/ (and please let me know if you have any questions.

source/Plugins/Language/ObjC/NSArray.cpp
221–228 ↗(On Diff #136332)

Do you mind to add comments to explain what the structure fields represent (or what this structure is for)?

source/Plugins/Language/ObjC/NSException.cpp
60–67

The fact we have to calculate this by hand is slightly annoying, but I guess that's a bug to fix another day.

kubamracek added inline comments.Feb 28 2018, 7:52 PM
packages/Python/lldbsuite/test/lang/objc/exceptions/TestObjCExceptions.py
2–5

Will do! I didn't realize we already have the lit infrastructure ready. Quick question: Can I test the SB layer from a lit test?

source/Plugins/Language/ObjC/NSArray.cpp
221–228 ↗(On Diff #136332)

There's many definitions of array layout throughout this file, so I don't see a comment to be necessary here. Basically, this just defines another layout of an array, see above for other instances.

source/Plugins/Language/ObjC/NSException.cpp
60–67

I'll be happy to send follow-up patches. Do you have suggestions how to avoid these manual pointer calculations?

LG modulo the test. Update that, I'll take another look and approve it. Thanks for your contribution!

packages/Python/lldbsuite/test/lang/objc/exceptions/TestObjCExceptions.py
2–5

No not really. The lit tests are a super recent addition :)

source/Plugins/Language/ObjC/NSArray.cpp
221–228 ↗(On Diff #136332)

Fair enough.

source/Plugins/Language/ObjC/NSException.cpp
60–67

The way we do that in swift (or well, we're trying to do) is that of using remote mirrors. I'm not really aware of an equivalent mechanism in Obj-C, FWIW, but we should definitely think about it and have a chat (if you want, I don't think you should be signed up for cleaning up this).

For tests that run processes I don't think lit has any advantages over the dotest tests. For tests of a facility that's explicitly going to provide SB API's, testing them with dotest.py which is set up to be convenient to do SB API testing seems the correct thing to do. I think this test is fine as it, except for the inline comment about using run_to_source_breakpoint.

This seems like it is two patches, one fixing the NSCallStackArray data formatter, and one extracting fields from NSException. Is that right. I'm more asking to make sure I'm not missing something about this patch.

This looks fine to me, you might explore getting the offsets from the NSException type - that should be generally available since we can read it from the ObjC runtime even if we don't get it from debug info.

packages/Python/lldbsuite/test/lang/objc/exceptions/TestObjCExceptions.py
30–39

All this (and the self.line calculation) can be replaced by:

lldbutils.run_to_source_breakpoint("// Set break point at this line.", lldb.SBFileSpec("main.m"))

source/Plugins/Language/ObjC/NSException.cpp
60–67

It looks like we generally have a type for NSException - it's an ObjC class so we'll read it out of the runtime if we can't get it from debug information. You should be able to get the offsets from that rather than having to hand code them here.

This seems like it is two patches, one fixing the NSCallStackArray data formatter, and one extracting fields from NSException. Is that right. I'm more asking to make sure I'm not missing something about this patch.

I'll split the patch. There's actually probably 3 more-or-less independent parts: 1) NFC refactoring of NSException.cpp, 2) extracting fields from NSException, 3) NSCallStackArray data formatter.

source/Plugins/Language/ObjC/NSException.cpp
60–67

Does reading the offsets need to run the target or is it just inspecting memory?

jingham added inline comments.Mar 1 2018, 10:40 AM
source/Plugins/Language/ObjC/NSException.cpp
60–67

Reading the whole runtime was too slow if done from lldb, since we're chasing pointers around, so we do this with some injected code. So if you happen to be the first guy to ever ask about an ObjC type and its offsets, you might trigger this code. If you aren't the first guy, then it's just inspecting memory.

The NFC refactoring part of this is at https://reviews.llvm.org/D44073.

kubamracek updated this revision to Diff 136933.Mar 3 2018, 9:55 PM

I simplified what this patch is doing by removing the other independent parts. I extended the test to be testing both CLI text output and SB APIs (which also means it cannot be moved to a lit test).

The changes for _NSCallStackArray are at https://reviews.llvm.org/D44081.

davide requested changes to this revision.Nov 12 2018, 7:49 AM
davide added inline comments.
source/Plugins/Language/ObjC/NSException.cpp
157–164

can you clang-format this and add a comment? Thanks.

This revision now requires changes to proceed.Nov 12 2018, 7:49 AM
kubamracek marked an inline comment as done.
kubamracek added inline comments.
source/Plugins/Language/ObjC/NSException.cpp
157–164

This is already clang-formatted. Added comment.

davide accepted this revision.Nov 12 2018, 10:54 AM

LGTM. Thanks.

This revision is now accepted and ready to land.Nov 12 2018, 10:54 AM
kubamracek marked an inline comment as done.Nov 12 2018, 11:15 AM

Thanks for the review!

This revision was automatically updated to reflect the committed changes.