llvm dev - Dec 2014 - [LLVMdev] [lld] adding demangler for symbol resolution

On 4/4/2014 3:46 AM, David Chisnall wrote:
> On 3 Apr 2014, at 20:49, Shankar Easwaran <shankare at
codeaurora.org> wrote:
>
>> b) I am not planning to write a demangler. I was planning on using
abi::__cxx_demangle if there was one available and the first character in the
symbol was a _.
>>     If MSVC was defined, we would use the Undecorate API.
> The demangler that Howard wrote for libc++abi was intended to be general
and reusable.  It was rewritten eventually because it wasn't a good fit for
the C++ runtime library, but it would make sense to import it into one of the
LLVM libraries, as a good, general demangler is something that a lot of things
(including lldb) would benefit from.
+ Chandler/Rafael

I agree with this. I will try to move out the function from libc++ abi 
to lib/Support and see if what the reviewers would say.

Makes it much easier to call the functionality instead of each 
tool/component having a separate implementation.


Thanks

Shankar Easwaran

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the
Linux Foundation

Le 4 avr. 2014 à 17:05, Shankar Easwaran <shankare at codeaurora.org> a
écrit :
> 
> On 4/4/2014 3:46 AM, David Chisnall wrote:
>> On 3 Apr 2014, at 20:49, Shankar Easwaran <shankare at
codeaurora.org> wrote:
>> 
>>> b) I am not planning to write a demangler. I was planning on using
abi::__cxx_demangle if there was one available and the first character in the
symbol was a _.
>>>    If MSVC was defined, we would use the Undecorate API.
>> The demangler that Howard wrote for libc++abi was intended to be
general and reusable.  It was rewritten eventually because it wasn't a good
fit for the C++ runtime library, but it would make sense to import it into one
of the LLVM libraries, as a good, general demangler is something that a lot of
things (including lldb) would benefit from.
> + Chandler/Rafael
> 
> I agree with this. I will try to move out the function from libc++ abi to
lib/Support and see if what the reviewers would say.
> 
> Makes it much easier to call the functionality instead of each
tool/component having a separate implementation.
> 
Maybe you should base your work on the "old" libc++abi implementation
that was more flexible, but slightly overkill for libc++abi and so was replaced
by the current one.

You should be able to find it by browsing the libc++abi source history.


Jean-Daniel

Hi Shankar,

What's the progress of moving the demangler into LLVM? On Windows, I have
to use glog's demangler for now, but I just bumped into a bug in that code
that fails on demangling a function name.

On Fri, Apr 4, 2014 at 8:05 AM, Shankar Easwaran <shankare at
codeaurora.org>
wrote:
> On 4/4/2014 3:46 AM, David Chisnall wrote:
>
>> On 3 Apr 2014, at 20:49, Shankar Easwaran <shankare at
codeaurora.org>
>> wrote:
>>
>>  b) I am not planning to write a demangler. I was planning on using
>>> abi::__cxx_demangle if there was one available and the first
character in
>>> the symbol was a _.
>>>     If MSVC was defined, we would use the Undecorate API.
>>>
>> The demangler that Howard wrote for libc++abi was intended to be
general
>> and reusable.  It was rewritten eventually because it wasn't a good
fit for
>> the C++ runtime library, but it would make sense to import it into one
of
>> the LLVM libraries, as a good, general demangler is something that a
lot of
>> things (including lldb) would benefit from.
>>
> + Chandler/Rafael
>
> I agree with this. I will try to move out the function from libc++ abi to
> lib/Support and see if what the reviewers would say.
>
> Makes it much easier to call the functionality instead of each
> tool/component having a separate implementation.
>
>
> Thanks
>
> Shankar Easwaran
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
> by the Linux Foundation
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


-- 
- Welson
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141211/a2fa3d68/attachment.html>

Sorry, I am not working on that at present.

On 12/11/2014 1:01 PM, Welson Sun wrote:
> Hi Shankar,
>
> What's the progress of moving the demangler into LLVM? On Windows, I
have
> to use glog's demangler for now, but I just bumped into a bug in that
code
> that fails on demangling a function name.
>
> On Fri, Apr 4, 2014 at 8:05 AM, Shankar Easwaran <shankare at
codeaurora.org>
> wrote:
>
>> On 4/4/2014 3:46 AM, David Chisnall wrote:
>>
>>> On 3 Apr 2014, at 20:49, Shankar Easwaran <shankare at
codeaurora.org>
>>> wrote:
>>>
>>>   b) I am not planning to write a demangler. I was planning on
using
>>>> abi::__cxx_demangle if there was one available and the first
character in
>>>> the symbol was a _.
>>>>      If MSVC was defined, we would use the Undecorate API.
>>>>
>>> The demangler that Howard wrote for libc++abi was intended to be
general
>>> and reusable.  It was rewritten eventually because it wasn't a
good fit for
>>> the C++ runtime library, but it would make sense to import it into
one of
>>> the LLVM libraries, as a good, general demangler is something that
a lot of
>>> things (including lldb) would benefit from.
>>>
>> + Chandler/Rafael
>>
>> I agree with this. I will try to move out the function from libc++ abi
to
>> lib/Support and see if what the reviewers would say.
>>
>> Makes it much easier to call the functionality instead of each
>> tool/component having a separate implementation.
>>
>>
>> Thanks
>>
>> Shankar Easwaran
>>
>> --
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted
>> by the Linux Foundation
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the
Linux Foundation