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

[Dawn Perchik]

dawn added a comment.

In http://reviews.llvm.org/D10744#201163, @clayborg wrote:

> 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.


Yes.  And in that case the last module's CU which was read wins.  I'm willing to accept this edge case until lldb can be redesigned to handle it.

> 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 understand that that was the intent.

> 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.


Right.  For this, I propose adding the default language option so that the user can see these names demangled in the language of their choosing.  FYI, GDB has an override option, and if not set, it uses the language of the selected frame's CU, but getting the frame info to where the demangling/matching happens in lldb is a nightmare.

> 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.


I tried this approach first.  It was nearly impossible to pass the correct language down to GetDemangledName, as there were many layers of calls to get to the CU and/or frame.  It would have required changes to many classes and functions in order to pass the language to the demangled call.  I abandoned that approach after several attempts.  You would have rejected it due to the extra class members alone.

This patch solves many of the problems with minimal impact to other implementations and to the design of lldb.  I can put a giant FIXME/TODO comment in with your suggestions and an acknowledgement that this isn't perfect but it's the best we can do for now.  Please accept this patch as an interim solution?


Repository:
  rL LLVM

http://reviews.llvm.org/D10744