> On Oct 20, 2015, at 9:57 AM, Ramkumar Ramachandra <artag...@gmail.com> wrote: > > Greg Clayton wrote: >> Yes I have seen a bunch of problems like this on linux due to types being >> incomplete in the debug info (my guess). But I would like to verify that the >> manual DWARF indexing isn't to blame for this. We have great accelerator >> tables that the clang makes for us that actually have all of the info we >> need to find types and functions quickly, whereas all other platforms must >> run SymbolFileDWARF::Index() to manually index the DWARF. > > I'm on OS X, so none of this applies?
Yes, then you are using good accelerator tables. > >> I should be able to tell if you can send me an ELF file and say where you >> were and wait wasn't showing up correctly (which variables) in an exact code >> context (which file + line or exact line in a function). Then I can verify >> that SymbolFileDWARF::Index() is correctly indexing things so that we can >> find types and functions when we need them. > > I've been mulling over this problem: do you want to be able to run the > Mach-O, or do you just want to inspect it? The transitive closure of > the dependencies is atleast 30 .dylibs, and I can't take out that much > IP. I would just inspect a type for a variable that isn't showing up from a specific shared library. If you can send just the dSYM file for a library, and give me a specific function from a specific file and what variables were not showing up, I can inspect the DWARF and see why the type isn't showing up. So just a single dylib + its dSYM file. If you don't have a dSYM file next to your libfoo.dylib, you can easily create one: % dsymutil libfoo.dylib This will create a libfoo.dylib.dSYM file, which is linked DWARF from all the .o files that made the dylib. So if you can send me a copy of the dSYM file and a file + line (foo.cpp:11), or function + compile unit (function is "int foo(int)" inside "foo.cpp") and let me know which variable wasn't able to be expanded (name of variable), I should be able to tell you more. Greg _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
