Michael137 added a comment.
In D156774#4601705 <https://reviews.llvm.org/D156774#4601705>, @Endill wrote:
> I tested this patch together with the following new code:
>
> uint32_t TypeSystemClang::GetNumMemberEnums(lldb::opaque_compiler_type_t
> type) {
> using EnumIt =
> clang::DeclContext::specific_decl_iterator<clang::EnumDecl>;
> if (!type)
> return 0;
> clang::QualType qual_type =
> RemoveWrappingTypes(GetCanonicalQualType(type));
> clang::DeclContext *ctx = qual_type->getAsRecordDecl()->getDeclContext();
> return std::distance(EnumIt(ctx->decls_begin()),
> EnumIt(ctx->decls_end()));
> }
>
> CompilerType
> TypeSystemClang::GetMemberEnumAtIndex(lldb::opaque_compiler_type_t type,
> size_t index) {
> using EnumIt =
> clang::DeclContext::specific_decl_iterator<clang::EnumDecl>;
> if (!type)
> return CompilerType();
>
> clang::QualType qual_type =
> RemoveWrappingTypes(GetCanonicalQualType(type));
> clang::DeclContext *ctx = qual_type->getAsRecordDecl()->getDeclContext();
> size_t enum_index = 0;
> for (EnumIt enums_it(ctx->decls_begin()), enums_end(ctx->decls_end());
> enums_it != enums_end;
> ++enums_it, ++enum_index) {
> if (enum_index == index) {
> return CompilerType(weak_from_this(), *enums_it);
> }
> }
> }
>
> I created all the wrappers to make it available in Python. The result was
> unsatisfactory: this code doesn't even trigger
> `DWARFASTParserClang::ParseChildMembers` that this patch touches, and return
> 0 instead of 1. This doesn't change even if I trigger `ParseChildMembers` via
> other means before asking for a number of member enums in a type.
>
> Code I tested this on:
>
> using intptr_t = long;
> using uintptr_t = unsigned long;
>
> struct PointerIntPairInfo {
> enum MaskAndShiftConstants : uintptr_t {
> PointerBitMask =
> ~(uintptr_t)(((intptr_t)1 << 3) - 1),
> };
>
> int a{};
> };
>
> static uintptr_t dummy() {
> return PointerIntPairInfo::PointerBitMask;
> }
>
> int main()
> {
> PointerIntPairInfo p;
> __builtin_debugtrap();
> return p.a + foo();
> }
>
> If you have any suggestions what I missed or did wrong, please let me know.
>
> I'll continue with this patch nevertheless, but it's clear now that there's
> still a way to go until I can access that enum without going through slow
> expression evaluator.
What were your lldb commands when you tested this?
LLDB currently completes types lazily when it thinks it can. Does your new API
still fail if you run `expr p` prior? (the idea is that that would trigger
completion of the type and parse dwarf). If we dont ever call
`GetFullCompilerType` on your type LLDB will never try to pull in the definition
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D156774/new/
https://reviews.llvm.org/D156774
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
