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.
> On Jun 14, 2022, at 1:04 PM, David Blaikie via Dwarf-Discuss
> <dwarf-discuss@lists.dwarfstd.org> wrote:
>
> On Wed, May 18, 2022 at 9:53 AM David Blaikie <dblai...@gmail.com
> <mailto:dblai...@gmail.com>> wrote:
>>
>> On Wed, May 18, 2022 at 4:16 AM Robinson, Paul <paul.robin...@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@lists.dwarfstd.org <mailto:Dwarf-Discuss@lists.dwarfstd.org>
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
> <http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org>
_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
