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.
Details
Diff Detail
Event Timeline
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 | ||
64–71 | The fact we have to calculate this by hand is slightly annoying, but I guess that's a bug to fix another day. |
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 | ||
64–71 | 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 | ||
64–71 | 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 | ||
64–71 | 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 | ||
---|---|---|
64–71 | Does reading the offsets need to run the target or is it just inspecting memory? |
source/Plugins/Language/ObjC/NSException.cpp | ||
---|---|---|
64–71 | 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. |
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).
source/Plugins/Language/ObjC/NSException.cpp | ||
---|---|---|
161–168 | can you clang-format this and add a comment? Thanks. |
source/Plugins/Language/ObjC/NSException.cpp | ||
---|---|---|
161–168 | This is already clang-formatted. Added comment. |
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.