[lldb-dev] [BUG?] Confusion between translation units?
Greg Clayton via lldb-dev
lldb-dev at lists.llvm.org
Mon Oct 26 11:13:55 PDT 2015
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:
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:
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:
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">
> 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.
> 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.
>>> On Oct 23, 2015, at 9:45 AM, Ramkumar Ramachandra <artagnon at gmail.com> wrote:
>>> 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/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.
More information about the lldb-dev