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 <artag...@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 <gclay...@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 <artag...@gmail.com>
>>> wrote:
>>>
>>> Hi,
>>>
>>> On Wed, Oct 21, 2015 at 2:27 PM, Greg Clayton <gclay...@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.
>>
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
