[lldb-dev] What should SymbolFile::FindFunctions(..., eFunctionNameTypeFull, ...) do ?

[Greg Clayton via lldb-dev]

> On May 9, 2018, at 4:53 AM, Pavel Labath <labath at google.com> wrote:
> 
> On Tue, 8 May 2018 at 10:51, Pavel Labath <labath at google.com <mailto:labath at google.com>> wrote:
> 
> 
>> On Fri, 4 May 2018 at 17:31, Greg Clayton <clayborg at gmail.com> wrote:
>>>> On May 4, 2018, at 4:58 AM, Pavel Labath <labath at google.com> wrote:
>>>> Is it really OK? If our indexes will never contain the demangled
> names,
>>>> then the IRExecutionUnit lookups using the demangled names will always
>>>> fail. (Right now they will only succeed for manually indexed dwarf,
> but
>>>> this will change if I stop putting these names in the full index)
>> Shouldn't
>>>> we fix the IRExecutionUnit to not attempt these lookups in the first
>> place?
> 
>>> Yikes. I wasn't aware this was happening. What is the flow here? It
> tries
>> to lookup using a mangled name first and if that fails, then it tries to
>> demangle the name and then look that up? Are there cases where we don't
>> have mangled names in the debug info, yet we are able to construct a fully
>> qualified name and look that up?
> 
>>> It would be great if we don't need these fully qualified name lookups,
>> but if we do, we could fix this by looking up using the basename, then
>> filtering the results of the lookup to only those that match in the IR
> code.
> 
>> What happens here is that IRExecutionUnit gets a mangled name, and then
> for
>> some reason decides to demangle it and try a lookup that way (see
>> IRExecutionUnit::CollectCandidateCPlusPlusNames). The history is not
> really
>> clear about why this is done -- this code has been there since the
> function
>> was introduced in r260734. After I remove the indexing of demangled names
>> in the manual index, this code should become effectively dead. I'll try
>> removing it after that.
> 
> 
> So, I tried removing the demangled lookup in IRExecutionUnit, thinking that
> would be a no-op. Turns out that was only almost true. The reason it was
> not a no-op is because we have another "full name" index which contains
> demangled names inside the Symtab class (Symtab.cpp:341). That index also
> contains the mangled names, so normally the demangled names should not
> matter.
> However, they do matter for one particular case: constructors. Clang on
> linux likes to omit the the symbol for the full object constructor if it
> turns out to be identical to the base object constructor. Since these
> demangle to the same name, we manage to find the base constructor when
> looking for the full one. This is what makes calling constructors in
> expressions "work" most of the time.
> 
> So, my question is: Should we change the Symtab index to not include the
> demangled names as well? The constructor issue seems to be the only thing
> it is useful, but that can be handled in a different way as well.

I am all for that. It would be great to not have to store the fully demangled name in indexes, it would save memory and time. As long as we can still find the constructors, assignment operators and other default created C++ functions in another way.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20180509/f10ad316/attachment-0001.html>