llvm dev - May 2016 - RFC: Adding an itanium c++ demangler to lib/Support

We are trying out lld ELF on windows. It works great, but a big
difference from running it on linux is that it cannot demangle c++
names since there is no itanium demangler available on windows.

We have an implementation in libcxxabi/src/cxa_demangle.cpp. I see
that there was some discussion about having a version of that in
lib/Support, but I don't think a patch was ever posted.

So, some questions

* Is having an itanium demangler in lib/Support something people find
desirable or at least acceptable?
* The libcxxabi code is dual licensed, would the copy in lib/Support be as well?
* How much llvm-like should we try to make it? Should it take an
StringRef, return an Error and print to a raw_ostream? Or should it
look more like __cxa_demangle to try to make it easier to move code
in?

My current preference is probably to make it as llvm-like as possible
since I don't expect we will need to add new mangling features too
often.

Cheers,
Rafael

On 5 May 2016, at 13:47, Rafael Espíndola via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> * Is having an itanium demangler in lib/Support something people find
> desirable or at least acceptable?
Yes.
> * The libcxxabi code is dual licensed, would the copy in lib/Support be as
well?
Please don’t use the one from libcxxabi.  Howard wrote one that was initially in
libcxxabi but was replaced because it had memory requirements that were
incompatible with one of the use cases in libcxxabi (on the out-of-memory
exception path).  It is far more flexible and allows things to be hooked in at
various points in the parse.  I believe that this one was written entirely by
Howard during his time as an Apple employee so can likely be relicensed with
Chris’s permission if required.
> * How much llvm-like should we try to make it? Should it take an
> StringRef, return an Error and print to a raw_ostream? Or should it
> look more like __cxa_demangle to try to make it easier to move code
> in?
I believe that it should be a generally useful demangler.  __cxa_demangle has a
very poorly designed interface and is really only useful for turning mangled
names into strings.  The earlier one makes it easy, for example, to extract the
demangled name of each argument type for a function call.  This is something
that I can imagine being useful in JIT FFI contexts, for example.

David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3719 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160505/c80c53ca/attachment.bin>

I really want to start simple. So if adding a demangler the first
objective is to add one that lets us drop the HAVE_CXXABI_H.

After that it can be expanded.

Cheers,
Rafael


On 5 May 2016 at 08:58, David Chisnall <David.Chisnall at cl.cam.ac.uk>
wrote:
> On 5 May 2016, at 13:47, Rafael Espíndola via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>>
>> * Is having an itanium demangler in lib/Support something people find
>> desirable or at least acceptable?
>
> Yes.
>
>> * The libcxxabi code is dual licensed, would the copy in lib/Support be
as well?
>
> Please don’t use the one from libcxxabi.  Howard wrote one that was
initially in libcxxabi but was replaced because it had memory requirements that
were incompatible with one of the use cases in libcxxabi (on the out-of-memory
exception path).  It is far more flexible and allows things to be hooked in at
various points in the parse.  I believe that this one was written entirely by
Howard during his time as an Apple employee so can likely be relicensed with
Chris’s permission if required.
>
>> * How much llvm-like should we try to make it? Should it take an
>> StringRef, return an Error and print to a raw_ostream? Or should it
>> look more like __cxa_demangle to try to make it easier to move code
>> in?
>
> I believe that it should be a generally useful demangler.  __cxa_demangle
has a very poorly designed interface and is really only useful for turning
mangled names into strings.  The earlier one makes it easy, for example, to
extract the demangled name of each argument type for a function call.  This is
something that I can imagine being useful in JIT FFI contexts, for example.
>
> David
>

On Thu, May 05, 2016 at 08:47:54AM -0400, Rafael Espíndola via llvm-dev
wrote:
> * Is having an itanium demangler in lib/Support something people find
> desirable or at least acceptable?
+1 (desirable)

On 5 May 2016 at 08:47, Rafael Espíndola <llvm-dev at lists.llvm.org>
wrote:
>
> * Is having an itanium demangler in lib/Support something people find
> desirable or at least acceptable?
In my opinion, yes. Also, if or when we do this we should remove the
additional copy of the demangler in lldb.