Using the LLVM demangler.

Hi all,

We’re hoping to replace the demangler in some of our tools to use the LLVM demangler. We’d like to enhance it with missing functionality (legal names that it cannot demangle) and provide a set of tests that we use with the demangler that we currently use.

The demangler that is currently in the LLVM tree appears to be a copy of the libc++abi implementation, and there appears to be chat about replacing it with the fast demangler implementation in LLDB.

Could you please advise if we should put our contributing efforts into enhancing the fast demangler in LLDB so that it can replace the existing one or just work on what is already there.

Regards,

David Bozier
Technical lead of linker and binutils
SN Systems - Sony Interactive Entertainment
http://www.snsystems.com
https://twitter.com/SNSystemsEU

Hi all,

We’re hoping to replace the demangler in some of our tools to use the LLVM demangler. We’d like to enhance it with missing functionality (legal names that it cannot demangle) and provide a set of tests that we use with the demangler that we currently use.

The demangler that is currently in the LLVM tree appears to be a copy of the libc++abi implementation, and there appears to be chat about replacing it with the fast demangler implementation in LLDB.

I’m not aware of this discussion, do you have any pointer? The fast demangler in LLDB isn’t safe right now (libFuzzer and ASAN uncovered multiple issues last time I checked) and isn’t complete. When I talked with Kate, she told me that it is a lot faster than the libcxxabi one because it does not cover all the corner cases, I don’t know if it can be made robust and a full replacement without losing the performance advantage it has.

Could you please advise if we should put our contributing efforts into enhancing the fast demangler in LLDB so that it can replace the existing one or just work on what is already there.

I looked at it last year, but David Majnemer convinced me that starting a new one from scratch was likely the best way forward. He started to experiment with it but I don’t know where it went.

Note that for licensing reason (to be double checked, I’m not an expert), I believe contributions needs to be made to libcxxabi first and back-ported to LLVM (which is also something to consider before reusing the lldb one).

I'm not sure when the new demangler will be ready, so you can either
ask David (cc:ed) about it, or for a short-term solution implement the
missing features in libcxxabi and backport to LLVM.
The work is not entirely wasted as we gain new testcases to use when
we'll switch to the new demangler. I understand backporting isn't a
lot of fun but considering the two implementations are supposed to be
in sync (and if they're not, that should be fixed), it shouldn't be a
lot of work.

I’m not aware of this discussion, do you have any pointer?

The initial checkin comment of ItaniumDemangle.cpp says that the current implementation will be replaced with the fast lldb demangler once it is complete.

I’ve also seen the latest conversation here:

https://groups.google.com/forum/#!topic/llvm-dev/v_7OuWx8n1A

Which has left me a bit unclear what the long term direction is.

We’d be happy to look at trying to improve the LLDB demangler if that is considered the way to go, or we’re willing to help out where we can with David Majnemer’s work.

Alternatively we used to have our own in house demangler that is a bit out of date (missing C++11 features) which is something we could take a look at reviving, bringing up-to-date with the latest ABI changes and contribute.

Dave