- Allow the definition of synthetic formatters in C++ even when LLDB is built without python scripting support.
- Fix linking problems with the CXXSyntheticChildren
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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. |
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. |
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. |
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? |
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
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.
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!
Why these changes?