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

[Pavel Labath via lldb-dev]

On Tue, 8 May 2018 at 10:51, Pavel Labath <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.