This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Let 'v' command directly access ivars of _any_ self/this
ClosedPublic

Authored by kastiglione on Mar 3 2023, 2:41 PM.

Details

Summary

The v (frame variable) command can access ivars/fields of this or self. This
change relaxes the criteria for finding this/self.

There are cases where a this/self variable does exist, but are cases in which v did not
support direct access of ivars -- meaning the user would have to type this->field or
self->_ivar to access. This change allows those cases to also work without explicitly
dereferencing this/self.

For example:

__weak Type *weakSelf = self;
void (^block)() = ^{
   Type *self = weakSelf; // Re-establish strong reference.
   // ...
};

In this case, self exists but v wouldn't use it.

Diff Detail

Event Timeline

kastiglione created this revision.Mar 3 2023, 2:41 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 3 2023, 2:41 PM
Herald added a subscriber: ChuanqiXu. · View Herald Transcript
aprantl added a subscriber: aprantl.Mar 3 2023, 2:48 PM

Add tests; rebase

kastiglione edited the summary of this revision. (Show Details)Mar 6 2023, 12:18 PM
kastiglione published this revision for review.Mar 6 2023, 12:31 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 6 2023, 12:31 PM

From an end-user perspective, I like this.

lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
9819

Couple of questions for my understanding:

  1. Do you see any opportunities for this to spectacularly do the wrong thing in an ObjectiveC++ program by guessing the wrong language? I suppose this just tries to do a best effort?
  1. We're not using the DW_AT_APPLE_runtime_language attribute because it's only attached to Objective-C classes?
  1. We're not using the DW_AT_language of the DW_TAG_compile_unit because it won't help us in an ObjC++ program?
kastiglione added inline comments.Mar 7 2023, 11:42 AM
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
9819

We're not using the DW_AT_APPLE_runtime_language attribute because it's only attached to Objective-C classes?
We're not using the DW_AT_language of the DW_TAG_compile_unit because it won't help us in an ObjC++ program?

I am not sure how to answer these too. While this function is new, the logic and this code path which calls GetObjectPtrLanguage, is taken from the existing implementation. In other words, how the debug info is made use of, hasn't changed.

kastiglione added inline comments.Mar 7 2023, 12:27 PM
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
9819

Do you see any opportunities for this to spectacularly do the wrong thing in an ObjectiveC++ program by guessing the wrong language? I suppose this just tries to do a best effort?

I don't see any obvious ways to get it wrong, but can't rule it out entirely. The way this change is implemented, there should be no way to have a regression – everything that used to work should still work. There could be some case out there where, in objc++, the wrong choice is made between this/self, but that would result in the same "variable not found" message you'd get today in that case (since the implementation should have no regressions).

aprantl accepted this revision.Mar 7 2023, 4:52 PM
aprantl added inline comments.
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
9819

Sorry I didn't realize this was existing code! While there might be an opportunity the improve the existing implementation, that is orthogonal to this change. Carry on.

This revision is now accepted and ready to land.Mar 7 2023, 4:52 PM