Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Is this fixing a specific situation and if so, can a test be written for it? I'm sure we have existing tests you can adapt.
lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp | ||
---|---|---|
492 ↗ | (On Diff #445081) | I think you want to make code changes here to look at mpi.Representation. |
762 ↗ | (On Diff #445081) | This codepath seems specific to global variable creation. Are there other ways to hit this issue through other codepaths, such as local variables or non-type template parameters? I would consider moving this logic closer to the logic which creates the AST member pointer type. Any time LLDB loads a member pointer type, it should check the inheritance kind, and then check if the class already has an MSInheritanceAttr, and add one if it is missing. If the existing attribute doesn't match the attribute you want to add, that represents an ODR violation in the user program. I'm not sure what LLDB should do in that case. |
lldb/source/Plugins/SymbolFile/NativePDB/UdtRecordCompleter.cpp | ||
319 | We shouldn't try to reimplement the frontend calculation logic, we should just trust the debug info. Users can use the pointers_to_members pragma to force the compiler to use different representations, so this calculation won't always be right. Also, I don't think this case handles multiple inheritance via indirect bases. Consider: struct A { int a; }; struct B { int b; }; struct C : A, B { int c; }; struct D : C { int d; }; If we need this logic in LLDB, try calling CXXRecordDecl::calculateInheritanceModel. |
Thanks!
lldb/source/Plugins/SymbolFile/NativePDB/PdbAstBuilder.cpp | ||
---|---|---|
840 ↗ | (On Diff #445942) | This should be virtual, not multiple, right? |
lldb/test/Shell/SymbolFile/NativePDB/ast-types.cpp | ||
111 ↗ | (On Diff #445942) | It's worth adding tests for data member pointers as well as function member pointers, in particular ones that use -1 as the null representation. Try this: int SI::*mp9 = nullptr; Because offset zero is a valid offset, -1 is used to represent null in this case. |
We shouldn't try to reimplement the frontend calculation logic, we should just trust the debug info. Users can use the pointers_to_members pragma to force the compiler to use different representations, so this calculation won't always be right.
Also, I don't think this case handles multiple inheritance via indirect bases. Consider:
If we need this logic in LLDB, try calling CXXRecordDecl::calculateInheritanceModel.