phyBrackets wrote:

> > However, GCC also tends to only emit debug info for static members when 
> > they're ODR-used and get storage,
> 
> Can we do that? (or do we already do that and this patch is about explicitly 
> doing something different?)
> 
> > Given that's a Clang-specific concern, I'm still happy to add a size cap if 
> > we think it's warranted. Or any other idea or path we need to look for?
> 
> Not sure - cap doesn't really inspire me & probably isn't worth a flag right 
> now. It's probably just going to be a matter of trying it in the wild and 
> seeing what breaks. Though I don't feel great about it (mostly don't feel 
> great about emitting debug info for things that aren't concretely in the 
> output binary - but I know that's at odds with constexpr stuff which is still 
> important for debugger users but doesn't have presence in the binary)

Hi @dwblaikie , I tested this locally to be sure,  turns out GCC actually does 
emit all three member DIEs (scalar, arr, f) inside the type unconditionally, 
even when nothing is ODR-used. And it attaches `DW_AT_const_value` to the array 
with the raw bytes, no size cap:

```
struct Foo { 
static constexpr int scalar = 42; 
static constexpr int arr[] = {1, 2, 3}; 
static constexpr float f = 3.14f; 
}; 

// Nothing ODR-used 
Foo foo; int main() { return 0; }
```

GCC:
  scalar: DW_AT_const_value (0x2a)
  arr:    DW_AT_const_value (<0x0c> 01 00 00 00 02 00 00 00 03 00 00 00)
  f:      DW_AT_const_value (<0x04> c3 f5 48 40)

Clang (trunk, without this patch):
  scalar: DW_AT_const_value (42)
  arr:    (declaration only, no const_value)
  f:      DW_AT_const_value (1078523331
  
So GCC's been doing exactly this for a while with no complaints. Clang already 
emits the arr declaration. Limiting to ODR-used only would be a separate 
broader change affecting all static constexpr members, including the scalars 
that already have const_value today.

https://github.com/llvm/llvm-project/pull/182442
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to