[Lldb-commits] [RFC] Type lookup for template types is broken...

[Frédéric Riss via lldb-commits]

> On May 8, 2018, at 2:23 AM, Pavel Labath <labath at google.com> wrote:
> 
> I am still building a picture for myself of how the accelerator tables and
> our name lookup works, but from what I managed to learn so far, adding an
> accelerator for "C" seems like a useful thing to do. However, this does go
> beyond what the DWARF 5 spec says we should do (we are only required to add
> the DW_AT_name string). We are still free to add any extra entries we like,
> but if we're going to be relying on this, we should try to get some of this
> into the next version of the spec.
> 
> 
> On Mon, 7 May 2018 at 22:19, Frédéric Riss via lldb-commits <
> lldb-commits at lists.llvm.org <mailto:lldb-commits at lists.llvm.org>> wrote:
> 
>> (...At least when using accelerator tables)
> 
>> If you apply the following patch, TestClassTemplateParameterPack.py will
> start failing:
>> diff --git
> a/packages/Python/lldbsuite/test/lang/cpp/class-template-parameter-pack/main.cpp
> b/packages/Python/lldbsuite/test/lang/cpp/class-template-parameter-pack/main.cpp
>> index 90e63b40f..304872a15 100644
>> ---
> a/packages/Python/lldbsuite/test/lang/cpp/class-template-parameter-pack/main.cpp
>> +++
> b/packages/Python/lldbsuite/test/lang/cpp/class-template-parameter-pack/main.cpp
>> @@ -37,7 +37,7 @@ template <> struct D<int, int, bool> : D<int, int> {
> 
> 
> 
>>  int main (int argc, char const *argv[])
>>  {
>> -    C<int,16,32> myC;
>> +    C<int,16,32> myC; //% self.runCmd("settings set
> target.experimental.inject-local-vars false")
>>      C<int,16> myLesserC;
>>      myC.member = 64;
>>      (void)C<int,16,32>().isSixteenThirtyTwo();
> 
>> The test does things like invoke methods on temporary template objects:
>> //% self.expect("expression -- C<int, 16>().isSixteenThirtyTwo()",
> DATA_TYPES_DISPLAYED_CORRECTLY, substrs = ["false"])
> 
>> The above expression currently works because there’s a local of type
> C<int, 16>. With injected locals, the type is made readily available to
> Clang. No type lookup is required for this to work in this setup.
> 
>> If you stop injecting locals, the test fails. We don’t provide the
> information to Clang to understand what C is. The reason is that when Clang
> parses “C<int , 16>”, it is going to ask about “C”, not the fully templated
> name. Our accelerator tables contain references to the full names, but not
> to C alone and we never find it. If I change Clang and dsymutil to add an
> accelerator for “C” each time an instance of C is seen then it nearly
> works. I just need this additional lldb patch:
>> diff --git a/source/Symbol/TypeMap.cpp b/source/Symbol/TypeMap.cpp
>> index 2838039ad..d2f2026bf 100644
>> --- a/source/Symbol/TypeMap.cpp
>> +++ b/source/Symbol/TypeMap.cpp
>> @@ -227,8 +227,11 @@ void TypeMap::RemoveMismatchedTypes(const
> std::string &type_scope,
>>        } else {
>>          // The type we are currently looking at doesn't exists in a
> namespace
>>          // or class, so it only matches if there is no type scope...
>> -        keep_match =
>> -            type_scope.empty() && type_basename.compare(match_type_name)
> == 0;
>> +        if (type_scope.empty()) {
>> +          keep_match = type_basename.compare(match_type_name) == 0 ||
>> +            (strlen(match_type_name) > type_basename.size() &&
>> +             match_type_name[type_basename.size()] == '<');
>> +        }
>>        }
>>      }
> 
>> I didn’t post this as a Phabricator review as it requires changes in llvm
> before doing anything in LLDB and I wanted to make sure we agree this is
> the right thing to do. I’m also not sure if this works out of the box on
> platforms without accelerator tables.
> 
> It won't work "out of the box", but it should be fairly simple to change
> our indexing code to add the extra entries, so that a lookup for "C" works
> the same way in both cases. BTW, how were you planning to compute the
> untemplated string ("C"). Will you just strip everything after the first
> '<' character, or were you thinking of something more fancy?

AFAIK, there are no fully qualified names in the debug info we generate so taking what’s before the first ‘<‘ should always return the class name. Does this logic seem flawed?

Fred


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20180508/fa6bfaf2/attachment-0001.html>