On Fri, 4 May 2018 at 17:31, Greg Clayton <clayb...@gmail.com> wrote: > > On May 4, 2018, at 4:58 AM, Pavel Labath <lab...@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 _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
