+David Majnemer <majne...@google.com> On Wed Feb 18 2015 at 10:58:26 AM Kate Stone <katherine_st...@apple.com> wrote:
> The new demangler was introduced in LLDB because while it does not yet > support the full Itanium ABI C++ mangling specification, LLDB often > demangles huge numbers of symbols to enable friendly breakpoint matching > commands. So it made sense to have a “fast path” even while a full > replacement wasn’t yet available. I think it makes a lot of sense to > migrate the project to LLVM once it covers more of the mangling > specification. > > I would be happy to correspond with anyone who is considering contributing > to the effort. > > Kate Stone k8st...@apple.com > Xcode Runtime Analysis Tools > > On Feb 18, 2015, at 10:49 AM, Zachary Turner <ztur...@google.com> wrote: > > FWIW there's been some discussion on this side about writing a new > ABI-agnostic demangler and putting in LLVM. That seems like the more > logical place for any kind of demangler, so hopefully we can coordinate so > that we don't duplicate effort. > > On Wed Feb 18 2015 at 10:45:57 AM Kate Stone <katherine_st...@apple.com> > wrote: > >> As this code is literally a copy of demangler sources from another >> project with strategic bug fixes I would recommend leaving it as is. It is >> possible that it will be replaced wholesale from time to time until I find >> the time to finish replacing it with the fast demangler. >> >> Kate Stone k8st...@apple.com >> Xcode Runtime Analysis Tools >> >> On Feb 18, 2015, at 10:27 AM, Zachary Turner <ztur...@google.com> wrote: >> >> Yea I figured this wasn't going to be a problem because the demangling >> path on Windows is like 10 lines to call into a Windows API to demangle for >> us. On the other hand, it looks like an easy fix to change it to not use >> template aliases. But since for all practical purposes Windows is the only >> platform that this matters for, I guess someone who is more of a style >> guide purist than me would have to make the change as I'm not motivated >> enough to do so. Looks like just a couple of simple replacements though. >> >> As long as we don't use template aliases for new code going forward >> though, I'm happy. They're mostly just syntactic sugar anyway, so they're >> never necessary to achieve something that you couldn't do otherwise. >> >> On Wed Feb 18 2015 at 10:21:45 AM <jing...@apple.com> wrote: >> >>> That code is actually from a copy of the llvm cxa_demangle.cpp (look at >>> the comment around line 33 of that file. >>> >>> We had to include this because the demangler that shipped with the >>> system for certain OS X releases crashed for some bad input. We couldn't >>> get a fix into the OS right away, so we put a fixed version into lldb. You >>> will only use it if you define LLDB_USE_BUILTIN_DEMANGLER, presumably you >>> wouldn't do that on Windows. >>> >>> I don't think we need to muck with this code... >>> >>> Jim >>> >>> >>> > On Feb 18, 2015, at 3:55 AM, Tamas Berghammer <tbergham...@google.com> >>> wrote: >>> > >>> > I removed the alias template from GDBRemoteCommunicationServerCommon.h >>> but there are still some template aliases in the code base. Based on my >>> first check (not necessarily complete) I find two more usage of template >>> aliases in source/Core/Mangled.cpp lines 4867 and 4868. I have no idea >>> about how that part of the code works and if it can cause any issue with >>> MSVC or not but we should consider removing it also (it is in the code base >>> since 2013-10-30). >>> > >>> > Tamas >>> > >>> > On Tue, Feb 17, 2015 at 11:33 PM, Zachary Turner <ztur...@google.com> >>> wrote: >>> > +lldb-dev@cs.uiuc.edu since this is of general interest. >>> > >>> > A little background: template aliases are a new C++11 feature. If you >>> aren't familiar with it, then the simple TL;DR version of it is that it's >>> like a template typedef. The syntax for using one looks like this: >>> > >>> > template<class T> >>> > using Foo = std::list<T> // Foo<T> is the same as std::list<T> now. >>> > >>> > Up until last weekend, LLVM's minimum toolchain requirement was MSVC >>> 2012, which did not support template aliases at all, so they were banned. >>> Last weekend we upgraded the minimum required version to MSVC 2013, which >>> we thought would allow template aliases to be used. Unfortunately, this is >>> not the case. A base install of MSVC 2013 with no updaets will still not >>> compile template aliases. I believe we're actually requiring MSVC 2013 >>> Update 4 as the baseline, but sadly this doesn't fix the problem. A fully >>> updated MSVC 2013 will compile them, but generate incorrect code. This is >>> more sinister, since it means you can use them, but the code won't work. >>> > >>> > As a result, template aliases are still banned until we upgrade the >>> minimum required version to 2015, which will still be a while as it's not >>> officially out yet. Please keep this in mind and try not to use them when >>> writing new code. Thanks! >>> > >>> > >>> > >>> > On Tue Feb 17 2015 at 3:21:03 PM Vince Harron <vhar...@google.com> >>> wrote: >>> > Hi Tamas, >>> > >>> > zturner@ informed me that MSVC 2013 doesn't generate correct code for >>> template alases. Can you remove your use on >>> > >>> > "GDBRemoteCommunicationServerCommon.h, lines 182 and 183" >>> > >>> > Thanks, >>> > >>> > Vince >>> > >>> > >>> > -- >>> > >>> > Vince Harron | Technical Lead Manager | >>> vhar...@google.com | 858-442-0868 >>> > >>> > >>> > _______________________________________________ >>> > lldb-dev mailing list >>> > lldb-dev@cs.uiuc.edu >>> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>> >>> _______________________________________________ >> lldb-dev mailing list >> lldb-dev@cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >> >> >> >
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
