This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Allow synthetic providers in C++ and fix linking problems
ClosedPublic

Authored by electriclilies on Aug 15 2023, 11:46 AM.

Details

Summary
  • Allow the definition of synthetic formatters in C++ even when LLDB is built without python scripting support.
  • Fix linking problems with the CXXSyntheticChildren

Diff Detail

Event Timeline

Herald added a project: Restricted Project. · View Herald TranscriptAug 15 2023, 11:46 AM
electriclilies requested review of this revision.Aug 15 2023, 11:46 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 15 2023, 11:46 AM
bulbazord added a subscriber: bulbazord.

Adding a few relevant reviewers :)

Moving the constructor/destructor to the cpp file makes sense to remove the "undefined reference to vtable" issues that we've seen before, but I don't understand the changes to pure virtual methods or the removal of the LLDB_ENABLE_PYTHON checks. Can you elaborate more?

lldb/include/lldb/DataFormatters/TypeSynthetic.h
257–262

Why these changes?

lldb/source/Commands/CommandObjectType.cpp
2174

Why is this dropped?

lldb/include/lldb/DataFormatters/TypeSynthetic.h
257–262

I thought that this was causing linking problems but it is not, so I will revert.

lldb/source/Commands/CommandObjectType.cpp
2174

Walter and I want to use the synthetic types from C++, but right now it's only supported in Python. The motivation behind this is to make it so that we can actually use the synthetic types.

jingham added inline comments.Aug 15 2023, 1:16 PM
lldb/source/Commands/CommandObjectType.cpp
2174

Just to be clear. There are already lots of synthetic child providers implemented in C++ in in lldb already (look for CXXSyntheticChildren constructors in CPlusPlusLanguage.cpp for instance).

I think what you are saying is that you are removing the restriction that you have to BUILD lldb with Python in order to add C++ implemented summaries. If that's indeed what you are saying, then this is fine, since that seems an odd restriction...

But it would be nice to have some kind of testing that this actually works, since I don't think any of our bots build lldb w/o Python.

electriclilies added inline comments.Aug 15 2023, 1:45 PM
lldb/source/Commands/CommandObjectType.cpp
2174

Yes that's exactly it! I agree it would be nice to have a test for it but I don't know how to add it.

@jingham Any other changes I should make? Thanks!

wallace edited the summary of this revision. (Show Details)Aug 22 2023, 9:15 AM
wallace added inline comments.
lldb/source/Commands/CommandObjectType.cpp
2174

@jingham , indeed, we couldn't add buildbot tests for this they all build with python support.

However, a good compromise is to enable all these commands except for the add ones, because they have the option to use python-defined extensions. clear, delete, info and list should be fine even without python scripting support.

What do you think?

wallace added inline comments.Aug 24 2023, 10:56 AM
lldb/source/Commands/CommandObjectType.cpp
2174

After a second inspection of this diff, I want to rephrase my previous comment:

This patch is only enabling the type synthetic commands, and type synthetic add is the only one that can receive a python input. In fact, it only works with python, so @electriclilies, please keep type synthetic add guarded by #if LLDB_ENABLE_PYTHON, because it just doesn't work otherwise.

@jingham , we can't really test this in the buildbots, so, all good if Lily does some basic manual testing showing that these commands work even when the python scripting support is not enabled?

@wallace The type synthetic add command already disables itself if python is not enabled (the check is at CommandObjectType::1564), so I think there aren't any changes I need to make

@wallace The type synthetic add command already disables itself if python is not enabled (the check is at CommandObjectType::1564), so I think there aren't any changes I need to make

Great! Let's wait for Jim then.

wallace accepted this revision.Aug 30 2023, 8:43 AM

For the sake of unblocking this diff, I'm accepting it because there's no clear actionable feedback at the moment. @electriclilies, please follow up any feedback that is submitted post-landing.

This revision is now accepted and ready to land.Aug 30 2023, 8:43 AM

Sorry, I got distracted, but after the fact I also agree this is reasonable.

We might actually be able to support externally adding C++ based synthetic providers, though I think the best way to do that is to add a way to make an SBTypeSynthetic from the appropriate C++ class, and then you could make that and add it in the lldb init function in the C++ library that adds the provider.

add a way to make an SBTypeSynthetic from the appropriate C++ class

That's a great idea. Once we implement a couple of providers for our plugin I'll revisit the idea. Thanks!