[lldb-dev] Can't use template aliases in LLDB

Zachary Turner zturner at google.com
Wed Feb 18 11:00:27 PST 2015


+David Majnemer <majnemer at google.com>

On Wed Feb 18 2015 at 10:58:26 AM Kate Stone <katherine_stone at 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 k8stone at apple.com
>  Xcode Runtime Analysis Tools
>
> On Feb 18, 2015, at 10:49 AM, Zachary Turner <zturner at 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_stone at 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 k8stone at apple.com
>>  Xcode Runtime Analysis Tools
>>
>> On Feb 18, 2015, at 10:27 AM, Zachary Turner <zturner at 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 <jingham at 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 <tberghammer at 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 <zturner at google.com>
>>> wrote:
>>> > +lldb-dev at 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 <vharron at 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 |
>>> vharron at google.com |    858-442-0868
>>> >
>>> >
>>> > _______________________________________________
>>> > lldb-dev mailing list
>>> > lldb-dev at cs.uiuc.edu
>>> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>
>>>  _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150218/1e416fbd/attachment.html>


More information about the lldb-dev mailing list