[Dwarf-Discuss] CU-local types

[David Blaikie]

On Tue, Jun 14, 2022 at 2:01 PM Greg Clayton <clayborg at gmail.com> wrote:
>
> Template types are emitted for C++ in DWARF as specialized instances only, there is no generic definition of the type. One of the issues that impedes LLDB from functioning correctly in the expression parser for C++ with templates is how the accelerator table entries are emitted. If you have a "std::vector<int>", the only accelerator table entry, if there is one at all, contains this full name ("std::vector<int>"). LLDB uses clang as the expression parser, so if someone types this into their expression, the end up with one entry that points this full name to the matching entry. LLDB acts and a precompiled header for clang when evaluating expressions, so first we will try and find "std" in the accelerator tables and we will find the namespace, then clang will ask for the name "vector" to be found within the "std" namespace and we will never find it since the name of a class is always fully specified. With functions we end up with the base name of the function as the DW_AT_name and we have the DW_AT_linkage_name for the mangled name, both of which will appear in the accelerator tables. But for classes we don't have the base name of the class at the DW_AT_name, so we never will find this template class unless we again ignore all accelerator tables and generate them ourselves each time we debug. Granted this can be fixed in LLDB at great cost of having to parse every DIE in all units each time we start debugging so we can make an index that works for these lookups, but that cost is prohibitive.

This is certainly an issue (though might be a bit different from what
you've described - at least at a quick glance it looks like for
"ns::t<int>" we get separate entries for "ns" and for the unqualified
"t<int>" (but not for "t") in the accelerator tables) - and with
simplified template names we may get "t" in the accelerator table
rather than "t<int>" (& so then you'll get "t" entries for "t<int>"
and "t<float>", etc... and have to disambiguate them)

But that's, I think, a different topic from the one this thread is
about - how to identify which types are CU-local and which types are
not. Maybe the template accelerated access issue would be worth
another/separate thread.

>
> On Jun 14, 2022, at 1:04 PM, David Blaikie via Dwarf-Discuss <dwarf-discuss at lists.dwarfstd.org> wrote:
>
> 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?
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>
>