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

[Greg Clayton via lldb-dev]

> On Oct 26, 2015, at 12:45 PM, Ramkumar Ramachandra <artagnon at gmail.com> wrote:
> 
> Greg,
> 
> Greg Clayton <gclayton at apple.com> wrote:
>> Note that for C++ we get the fully qualified name and we pass in an empty Declaration() so they all will compare to the same thing. This would solve our current issue. We would also need to add the items to this map in the same way: for C++ get the fully qualified name and add the entry to the map with the fully qualified name and an empty Declaration...
> 
> I didn't realize that the solution would be this simple, conceptually.
> 
>> Can you try this solution out and see if it fixes our issues?
> 
> This does seem to work for one library but not another.
> 
> My best guess would be that the solution works when dynamically
> linking to conflicting symbols, but not when the conflicting symbols
> are statically linked. Does that make sense?

Not really. If you can send me a concrete example of something that isn't working, it might help. When static linking occurs now we should have liba.dylib with llvm::foo::bar<int> defined on bar.h line 12 in the DWARF with:

~/src/llvm/include/llvm/foo/bar.h:12

and another whose decl file and line is:

/usr/local/include/llvm/include/llvm/foo/bar.h:12

The name that was being store was "bar<int>" with the byte size and one of the two decl file and lines from above. Is this the static linking case you meant above when you stated  "but not when the conflicting symbols are statically linked"? If so, our current fix would enter the type in with the name "llvm::foo::bar<int>" and with an empty decl file and line. Then both cases from the above previously failing static linking case would work because they would avoid using the decl file + line to differentiate the two types. Does this make sense?