clayborg wrote: > > The DWARFASTParserClang.cpp will try to create the class from the DWARF for > > the class definition. You will need to find the DW_TAG_variable when we are > > creating the static field if there is no DW_AT_const_value in the > > DW_TAG_member. But we also need to support the DW_AT_const_value being in > > the DW_TAG_member since older DWARF will be emitted like this. > > That's 100% correct. I was thinking, before [this > block](https://github.com/llvm/llvm-project/blob/8b91de5d6a3f98dcc00bbd286e339e512f7e3682/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp#L2909-L2919) > where we check for the existence of a `const_value_form`, we could try to > look for the definition and take the constant off of that. > > What's interesting is that with this patch, the expression evaluator > successfully finds the `DW_TAG_variable`s which have a location attribute but > not if they have a constant instead of a location. It's probably some logic > that assumes statics always have a location
The DWARFASTParserClang, with the current state of things, will automatically add the const value initializer to the clang AST field. See `DWARFASTParserClang::ParseSingleMember(...)` around the `// Handle static members` around lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:2882. The code extracts the `llvm::Expected<llvm::APInt> const_value_or_err` and then calls `TypeSystemClang::SetIntegerInitializerForVariable(v, *const_value_or_err);` to set the constant value of the static member. I think the expression parser knows how to grab this value if it is in a static member variable. If this isn't there, it assumes there is a global variable that backs it and that we will be able to find the location of this variable in memory. The expression parser will ask for the address of this value during expression evaluation when it resolves the symbols. > > > Are we going to emit a DW_AT_const_expr now in the DW_TAG_member? If so, > > then we will know that we need to look for the DW_TAG_variable. I don't > > think clang emitted the DW_AT_const_expr attribute before. > > That wasn't part of this patch. But would make sense to add (i've noticed GCC > adds that attribute) It would be nice to add this as a way to indicate this is a constexpr and that we need to do something special with it. Is there anyway we can just leave the `DW_AT_const_value` in the `DW_TAG_member` and then have the `DW_TAG_variable` point to the `DW_TAG_member` using a `DW_AT_specification` or `DW_AT_abstract_origin`? My guess this isn't great DWARF where we have a `DW_TAG_variable` have a specification or abstract origin that points to a different DWARF tag. Or maybe we can include the DW_AT_const_value in both places? https://github.com/llvm/llvm-project/pull/70639 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
