[lldb] [clang] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)

[Michael Buch via cfe-commits]

Michael137 wrote:

> 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.

Yup, what i was trying to explain is that with the current patch this will break because the expression evaluator neither finds the constant on the declaration (since we removed it) nor via symbol resolution (since they just won't exist for constants).

My point was just that if we are to drop the constant from the declaration, we'll have to amend that DWARFASTParserClang logic that you linked so it finds the correct variable definition and take the constant off of that.

> 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.

I agree, though i think that can be done in isolation as a follow-up PR.

> 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.

The variable definition *will* have a specification back to the declaration.

> Or maybe we can include the DW_AT_const_value in both places?

The ask to drop the constant off of the declaration comes from the DWARFParallelLinker work where it was causing non-deterministic output. But @dwblaikie @avl-llvm will know more about that



https://github.com/llvm/llvm-project/pull/70639