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

[Pavel Labath via lldb-dev]

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 things we need to think about:
> >> - do we make SymbolFile interfaces simpler and make the filtering logic
> > at a high level, or do we increase the complexity of these searches so
they
> > return fewer results and have each SymbolFile::FindXXXX() function more
> > complex.
> >> - do we agnostify the CompilerDeclContext so it works on any type
system,
> > or require the find function that searches multiple modules have to
create
> > or lookup a valid CompilerDeclContext prior to calling into each
> > SymbolFile::FindXXX() call?
> >
> > These are very good questions, but I am afraid I don't know enough about
> > this part of the codebase to say what would be best. I think that a
> > declarative method of specifying the context would be better than a
> > callback-based, because then the search can be optimized better (e.g.
for
> > DWARF 5 indexes, knowing the offset of the compile unit we are searching
> > can make the searches much faster, but I'm not sure about the details.
It
> > looks like I will be digging in this part of the code for a while now,
so I
> > may get a better idea of how it is used...

> Sounds good. I know this area very well and am happy to help explain and
get you up to speed. We put a lot of thought into the Apple accelerator
tables and they have been working very well for us, so I will be happy to
see these related DWARF 5 accelerator tables being added.

> BTW: it would be great if we modify llvm-dsymutil to generate these
tables and to also handle ELF. llvm-dsymutil has a "--update" option that
takes an existing DWARF file and adds the apple accelerator tables to
existing DWARF. Having a tool that can add the DWARF 5 accelerator tables
would be great for older compilers that don't generate these tables, but
can have them generated. Another idea would be to be able to generate these
accelerator tables on the side and cache them somewhere. LLDB could
determine that a DWARF file doesn't have them, and generate them on the fly
and cache them. We already basically generate these indexes in memory when
calling ::Index(...), so why not just generate them into stand alone side
files and cache and use them. This would speed up subsequent debug sessions
in new processes since we can just load the cached file. Then we only have
to support one indexing format. The LLVM code built into LLDB has all the
code it needs to generate this info? Thoughts?


I am keeping that idea in mind, but it's not at the top of my queue right
now. First I want to make sure everything works well in the "ideal"
scenario where everyone uses a compatible compiler and we don't have to do
any extra work (in debugger or elsewhere). Then I'll take a look at how to
handle the legacy workflow.

pl