[lldb-dev] [BUG?] Confusion between translation units?
Ramkumar Ramachandra via lldb-dev
lldb-dev at lists.llvm.org
Mon Oct 26 11:00:26 PDT 2015
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
Now, ~/src/llvm-build/lib/libLLVMCore.a contains DWARF information
that points to files ~/src/llvm/include/llvm/ADT/ilist.h,
~/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.
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