[Dwarf-Discuss] CU-local types

[David Blaikie]

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.

- Dave