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

On 4/3/2014 12:58 AM, Nick Kledzik wrote:
> On Apr 2, 2014, at 11:02 AM, Shankar Easwaran wrote:
>
>> On 4/2/2014 12:23 PM, Nick Kledzik wrote:
>>> On Apr 1, 2014, at 9:19 PM, Shankar Easwaran wrote:
>>>
>>>> The API's that would be in LinkingContext would be :-
>>>>
>>>>         * virtual bool canDemangle()  = 0; // Does the flavor
provide a way to demangle symbol names ?
>>>>         * virtual std::string demangle(StringRef symbolName) =
0; // demangle the symbol name
>>>>
>>>> Thoughts / Suggestions ?
>>> Wouldn't it be simpler to have one demangle() method that does
nothing (returns input string) if demangling is not available, the string is not
a mangled symbol, or demangling was turned off (--no-demangle).   Then, you just
wrap a demangle() call around every use.
>> Are you mentioning that one demangle function in LinkingContext ?
> Yes.  How do you expect clients to use your proposed
canDemangle()/demangle() interface?   Seems like it would always be:
>    str = sym;
>    if (ctx.canDemangle())
>       str = ctx.demangle(sym);
>
> My suggestion is to move the canDemangle functionality into demangle, so
clients just always use:
>      str = ctx.demangle(sym);
> and it returns the input string if a demangler is not available or is
disabled.
>
Yes. This would be much preferrred.
>> One demangle method wouldnt work as the ItaniumABI uses one method to
demangle, ARMCXXABI uses a different method, and MSVC uses a different one. I am
not sure about Mach-O here ?
> Given that, how can we make an lld tool that cross builds the same as it on
the native system?  Are you thinking of writing your own demangler?  Or use
whatever one is natively available, and fall back to not demangling if the
native demangler cannot demangle the given symbol name (e.g. an MSVS symbol on
when running on linux).
a) The function would be non-virtual.
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.

Does this look good ?
>
>>> The __cxa_demangle function has an odd interface that requires a
malloc allocated block.  Having demangle() return a std::string means yet
another allocation. We might not care if this is just used in diagnostic
outputs, but a more efficient way would be to pass the stream object to demangle
and have it write directly to the stream instead of creating a std::string.
>> I dont know if diagnostics in clang, already redirect things directly
to a stream.
>>
>> May be for now, as an initial implementation, we can have a single
demangle function that returns a std::string.
> Lets look at an example, lld currently has:
>              llvm::errs() << "lld warning: shared library symbol
"
>                                << curShLib->name()
>                                << " has different load path in
" …
>
> My ideal change would be to something like:
>
>              llvm::errs() << "lld warning: shared library symbol
"
>                                << ctx.demangle(curShLib->name())
>                                << " has different load path in
" …
>
I think we are on the same page. ctx.demangle() would return a string I 
assume in your case as well.

Thanks

Shankar Easwaran

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

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.

David

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