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

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
>

+Kate

We already have two demangler implementations (LLDB and libcxxabi).  I'd
rather not have three.  Have you looked at the LLDB one?  I think Kate has some
patches she hasn't had a chance to commit yet that add functionality.  I
heard something like 10x faster, and way less stack usage (although not quite
fully functional yet).  Seems like a good starting point.

I don't have a problem with "the one true demangler" living in
lib/Support, but ideally we'd find a way to reuse it in libc++abi so that we
have one, well-tested, implementation.
> On 2016-May-05, at 06:37, Rafael Espíndola via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 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
>> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Having a single one for llvm and lldb should be "easy", I am OK with
starting by just moving the lldb one to llvm.

I guess it should be possible to have libc++abi link with lib/Support
and fetch a single object file, but that means not using other parts
of llvm in the implementation (no StringRef, Error or raw_ostream).

Is the implementation in lldb dual licensed?

Cheers,
Rafael



On 5 May 2016 at 13:58, Duncan P. N. Exon Smith <dexonsmith at apple.com>
wrote:
> +Kate
>
> We already have two demangler implementations (LLDB and libcxxabi). 
I'd rather not have three.  Have you looked at the LLDB one?  I think Kate
has some patches she hasn't had a chance to commit yet that add
functionality.  I heard something like 10x faster, and way less stack usage
(although not quite fully functional yet).  Seems like a good starting point.
>
> I don't have a problem with "the one true demangler" living
in lib/Support, but ideally we'd find a way to reuse it in libc++abi so that
we have one, well-tested, implementation.
>
>> On 2016-May-05, at 06:37, Rafael Espíndola via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>>
>> 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
>>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

On Thu, May 5, 2016 at 10:58 AM, Duncan P. N. Exon Smith via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> +Kate
>
> We already have two demangler implementations (LLDB and libcxxabi). 
I'd
> rather not have three.  Have you looked at the LLDB one?  I think Kate has
> some patches she hasn't had a chance to commit yet that add
functionality.
> I heard something like 10x faster, and way less stack usage (although not
> quite fully functional yet).  Seems like a good starting point.
>
> I don't have a problem with "the one true demangler" living
in
> lib/Support, but ideally we'd find a way to reuse it in libc++abi so
that
> we have one, well-tested, implementation.
>
IIRC, LLDB has two demanglers: one is a copy of the libc++ demangler and
the other is a "fast-path" demangler.  There are some cases that the
fast-path demangler cannot handle which leads it to fall back to the libc++
clone.

My professional opinion, having worked a lot with mangling technology,
would be for us to write a new mangler that had incredibly few dependencies
on anything.  This would make it easy for us to copy the source or an
object file generated by the source.

>
> > On 2016-May-05, at 06:37, Rafael Espíndola via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > 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
> >>
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160505/aa8e0d54/attachment.html>