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

[Greg Clayton via lldb-dev]

So when LLDB parses the DW_AT_decl_file attributes, it uses the files from the line table for the current compile unit. Each of those files is passed through the module source remapping function:

bool
Module::RemapSourceFile (const char *path, std::string &new_path) const
{
    Mutex::Locker locker (m_mutex);
    return m_source_mappings.RemapPath(path, new_path);
}

So if you have a plist, it should be being added to this m_source_mappings list. You might want to debug what is happening by stepping through:

SymbolVendorMacOSX::CreateInstance()

for the dSYM file that is being used by your build. Inside the "if (XMLDocument::XMLEnabled())" statement is where we get the path remappings.

A quick note on the plist files in the dSYM: you must create one for each UUID plist for each architecture slice inside the dSYM bundle:

/tmp/foo.dSYM/Contents/Resources/9FE9CADA-7460-3F80-B881-42443C5FA2E1.plist
/tmp/foo.dSYM/Contents/Resources/DF977301-4A63-32ED-9939-1EE3122D18D4.plist

And an example plist for you would need to look like:

% cat /tmp/foo.dSYM/Contents/Resources/9FE9CADA-7460-3F80-B881-42443C5FA2E1.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>DBGBuildSourcePath</key>
	<string>~/src/llvm/include/llvm</string>
	<key>DBGSourcePath</key>
	<string>/usr/local/include/llvm</string>
</dict>
</plist>


> On Oct 26, 2015, at 11:00 AM, Ramkumar Ramachandra <artagnon at gmail.com> wrote:
> 
> Okay, I'm stuck again. Let's back up and see what's happening:
> 
> ~/src$ git clone llvm/
> ~/src$ mkdir llvm-build/
> ~/src/llvm-build$ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug ../llvm
> ~/src/llvm-build$ ninja
> 
> Now, ~/src/llvm-build/lib/libLLVMCore.a contains DWARF information
> that points to files ~/src/llvm/include/llvm/ADT/ilist.h,
> ~/src/llvm/lib/IR/Core.cpp etc.
> 
> ~/src/llvm-build$ ninja install
> 
> The *.a files are copied to /usr/local/lib, but the *.h files are also
> copied to /usr/local/include/llvm. The DWARF information is not
> rewritten as part of the "install".
> 
> ~/src/fooapp$ clang++ -g -I/usr/local/include -L/usr/local/lib ...
> 
> The fooapp binary is going to contain DWARF information pointing to
> /usr/local/include/llvm/ADT/ilist.h (because I did -I) _and_
> ~/src/llvm/include/llvm/ADT/ilist.h (because of libLLVMCore.a).
> 
> lldb crashes. gdb hums along just fine in the face of this conflict
> (the codebase is enormous; sorry, I couldn't find out how exactly).
> 
> Now, I cannot "fix" my build by -I'ing ~/src/llvm/include because some
> essential headers are build artifacts. The only thing I can do is to
> try and put a plist into the dSYM (which doesn't seem to work either,
> or I'm doing something wrong). In the general case, there's nothing
> special about my build: this problem needs to be solved in lldb for
> the general audience.
> 
> Please advise.
> 
> Thanks.
> 
> Ram
> 
> On Fri, Oct 23, 2015 at 1:00 PM, Greg Clayton <gclayton at apple.com> wrote:
>> I guess LLDB was just helping your resolve build issues and make your product better... :-)
>> 
>> Let us know how things go once you get your build fixed.
>> 
>> Greg
>> 
>>> On Oct 23, 2015, at 9:45 AM, Ramkumar Ramachandra <artagnon at gmail.com> wrote:
>>> 
>>> Hi,
>>> 
>>> On Wed, Oct 21, 2015 at 2:27 PM, Greg Clayton <gclayton at apple.com> wrote:
>>>> ....
>>> 
>>> Atleast, can we have lldb report a nicer error?
>>> 
>>> There is conflicting DWARF information for type ilist...:
>>> /sandbox/rramacha/3p/derived/List.h
>>> /sandbox/rramacha/3p/install/List.h
>>> 
>>> /sandbox/rramacha/idivide/bin/libmwcgir_vm.so is to blame.
>>> 
>>> This is likely a problem with your build scripts. In any case, the
>>> compiler is responsible for this mess.
>>> 
>>>> It sounds like you fixed your symlink issue. So a few questions:
>>>> 1 - do you have just one type now in your libmwcgir_vm_rt.dylib.dSYM when you type:
>>>> 
>>>> (lldb) image lookup -t "iplist<llvm::Function, llvm::ilist_traits<llvm::Function> >"
>>>> 
>>>> If so, then you will need to find other competing definitions in other shared libraries and see if any of them differ by comparing the full "clang_type" value.
>>> 
>>> Yeah, after resolving the symlink, I realized that there are two
>>> different paths. I'm attempting to fix my build system.
>>