Michael137 wrote:
> > That's true, if defined in a header, we'll emit a DW_TAG_variable for the
> > constant in each compile unit the header is included in. GCC does do the
> > right thing and only emit the definition DIE in a single CU. We should
> > probably do the same. Though not sure at which level we want to catch that.
>
> Which variable are you discussing here, `val1` or `val2`?
>
> For `val1`, we could not emit the constant value and only emit the real
> definition (there's /some/ risk here - non-ODR uses (or otherwise optimized
> away uses) of the variable may mean that the object file that defines the
> variable won't be linked in - so we'd miss the constant value) For `val2` the
> variable is effectively `inline` and doesn't have a home, so there's no one
> place that we can emit the `DW_TAG_variable` out-of-line definition...
Sorry for the confusion. I wasn't referring to that code snippet.
Also, I must've not looked at the GCC dwarfdump output carefully enough.
Compiling two CUs that include a class with a `static constexpr` member will
produce two separate definitions and two entries in `.debug_pubnames`:
```
.debug_pubnames
global die-in-sect 0x00000070, cu-in-sect 0x0000000c, die-in-cu 0x00000070,
cu-header-in-sect 0x00000000 'Foo::val2'
global die-in-sect 0x0000007b, cu-in-sect 0x0000000c, die-in-cu 0x0000007b,
cu-header-in-sect 0x00000000 'main'
global die-in-sect 0x00000118, cu-in-sect 0x000000b4, die-in-cu 0x00000070,
cu-header-in-sect 0x000000a8 'Foo::val2'
global die-in-sect 0x00000128, cu-in-sect 0x000000b4, die-in-cu 0x00000080,
cu-header-in-sect 0x000000a8 'Foo::func'
```
So to answer Greg's question, yes we will potentially produce multiple variable
definition DIEs. One for each CU that the header was included in
https://github.com/llvm/llvm-project/pull/70639
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
