[Lldb-commits] [PATCH] D10744: Fix demangling of names if required by language

[Greg Clayton]

clayborg added a comment.

Greg: The other problem is we might have two symbols, one from Pascal and one from C++ that could have the same mangled name for different private non-exported symbols in two different shared libraries like "foo::bar" in C++ and "foo.bar" in pascal.

Dawn: Those should result in duplicate definition errors in the linker.

No they wouldn't if they were private symbols in two different shared libraries. So this can happen.

Dawn: Ideally lldb would have been designed more like gdb, where the demangling is done on the fly and '__ZN2ns4funcEi' would appear as 'ns.func' in a C++ context and 'ns.func' in a Pascal context, but the current design of lldb won't allow for that without major overhaul.

So demangling is very expensive and caching the results is a good design decision.

I agree we need to fix this in LLDB, but demangling a name incorrectly and playing with that for a while and then changing it later ins't a good fix either. So lets find a way to fix this, and do it right.

So the major problems we still have that we haven't solved:
1 - when we just have a symbol table, we have NO way of knowing how to demangle a name and we might show it incorrectly in stack backtraces if we don't have debug info. I have no solution for this unless object files contain some sort of tracking on what functions are pascal and I doubt we can do this.
2 - If we do have debug info we might need more than one demangling for a given mangled name, right now we only store one. We currently do this by storing the C++ demangled name in the StringPool entry. StringPool entries in the constant string pools have two "const char *" entries and it currently contains the demangled/mangled names for C++ or the mangled/demangled name for C++. This saves us a ton of time as we never have to demangle a name twice and demangling is very very expensive so this design will stay here. Why? Because the way GCC and clang make debug info, they duplicate std::string, and all STL types in each .o file so that means we end up with tons of duplicated mangled names in many many many .o files. We need to find a way to fit it demangling in for Pascal and Java.

So I propose that it is ok to have the Mangled::GetDemangledName() take a language:

const ConstString&
Mangled::GetDemangledName (lldb::LanguageType language) const

Then if the language isn't pascal or java, do what we currently do, no changes. If not, we create a side table for each language that demangles differently and store the results there using the code that you used to change the mangled name over. Then we just need to find the calls to GetDemangledName() and supply a language where we need to. This shouldn't be too hard to do.


Repository:
  rL LLVM

http://reviews.llvm.org/D10744