[lldb-dev] [BUG?] Confusion between translation units?

Greg Clayton via lldb-dev lldb-dev at lists.llvm.org
Tue Oct 20 11:32:57 PDT 2015


> On Oct 20, 2015, at 9:57 AM, Ramkumar Ramachandra <artagnon at 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


More information about the lldb-dev mailing list