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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161215/b057fa22/attachment.html>
> On Dec 15, 2016, at 6:18 AM, Dave Bozier via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > 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). — Mehdi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161215/dbc2c231/attachment.html>
On Thu, Dec 15, 2016 at 6:18 AM, Dave Bozier via llvm-dev <llvm-dev at lists.llvm.org> wrote:> 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. > >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. -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare
> 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 On Thu, Dec 15, 2016 at 5:53 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:> > On Dec 15, 2016, at 6:18 AM, Dave Bozier via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > 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). > > — > Mehdi > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161216/a2067569/attachment.html>