phyBrackets wrote:

> > but I think DW_AT_const_value helps in cases where it doesn't for eg if the 
> > variable is never odr used, the linker can discard it entirely, and there 
> > would be no memory location to read, and remote debugging where reading 
> > target memory is expensive or unavailable.
> 
> `[[gnu::used]]` can prevent the deduplication if desired and expensive target 
> memory reads I'm personally not sure is a strong argument for adding more 
> debug-info. It'd be good to have at least a known use-case of the constant 
> being optimized out by Clang in a way which makes inspecting it in the 
> debugger not work. I'm not claiming that there are no cases like that, but 
> it'd be at least a valid motivator.
> 
> Re. GCC compatibility. Yes compatibility is a good goal, but in my opinion 
> not if that's the only goal.
> 
> And yea some DWARF consumers probably do care about debug-info size increase, 
> so running `bloaty <clang object files after patch> -- <clang object files 
> before patch>` would be helpful. But probably best to hold off until people 
> think this is something worth pursuing

Thanks for explanation. Few things that I found regarding this, that might  
make sense, clang already emits `DW_AT_const_value` for `static constexpr int` 
and `static constexpr float` members, and this patch would be extending the 
same treatment to arrays of those element types, if it wasn't worth the dwarf 
cost for scalars, it wouldn't be added.

Relatedly, @dwblaikie filed https://github.com/llvm/llvm-project/issues/102676 
about intermittently missing `DW_AT_const_value` for scalar constexpr static 
members and labeled it wrong-debug, suggesting the community considers emitting 
these values the correct behavior.

on `[[gnu::used]]` , on elf targets it actually doesn't prevent linker section 
GC , and requiring source annotations to preserve debuggability isn't great. 

But open to other feedbacks, and maybe if we all agree we could have a 
discussion over discourse.

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