[Dwarf-Discuss] CU-local types

[David Blaikie]

On Wed, May 18, 2022 at 9:53 AM David Blaikie <dblaikie at gmail.com> wrote:
>
> On Wed, May 18, 2022 at 4:16 AM Robinson, Paul <paul.robinson at sony.com> wrote:
> >
> > > Looks like gdb and lldb both have issues with C++ local types (either
> > > types defined in anonymous namespaces, or otherwise localized - eg: a
> > > non-local template with a local type or variable in one of its
> > > parameters).
> > > ...
> > > So... what could/should we do about this?
> >
> > Do you have a strong argument for why these are not debugger bugs?
> > It sounds to me like gdb/lldb are handling anonymous namespaces
> > incorrectly, in effect treating their contents as global rather than
> > CU-local.
>
> Oh, right, sorry forgot to include the trickier examples.
>
> So for a non-template this isn't especially burdensome (check for an
> anonymous namespace in the parent scopes - it's language specific, but
> not a ton of weird work to do) - for templates it's a bit harder (you
> have to check every template parameter, and potentially arbitrarily
> deep - eg: you might have a template parameter that's a function type
> and one of the parameters is a pointer type and the type the pointer
> points to is local - thus the template is local. That seems a bit more
> of a stretch to ask the consumer to do totally reliably) - but the
> worst case, that at the moment there's potentially no way to
> disambiguate whether the type is local or not: A non-type template
> parameter that points to a local variable.
>
> static int x = 3;
> template<int *> struct t1 { };
> t1<&x> v;
>
> Currently both LLVM and GCC name this type "t1<&x>" and LLVM at least
> puts a DW_AT_location on the DW_TAG_template_value_parameter which
> points to the global variable (not the DW_TAG_variable, but to the
> actual ELF symbol in the file) - though this choice has some negative
> effects (causes the symbol to be "used" and linked in - which means
> that enabling debug info can effect the behavior of the program
> (global ctors in that file execute when they wouldn't've otherwise,
> etc)).
>
> If the location is provided, arguably the consumer could lookup the
> symbol and check its linkage (not always accurate - LTO might've
> internalized a variable that wasn't actually internal in the original
> source, for instance) - but when the location is not provided there's
> no way to know whether "t1<&x>" is local or not.

Ping - anyone got further ideas about how to address this issue/encode
this information?