[LLVMdev] [lld] adding demangler for symbol resolution

[Rui Ueyama]

I agree that LinkingContext should be the right place to have a function
for demangling. Such feature is needed. It'd be useful in many situations
such as printing an error message or logging. But I'd want to keep the
number of API's each LinkingContext needs to support minimum, at least for
now, as we can add more as we need it.

On Tue, Apr 1, 2014 at 9:19 PM, Shankar Easwaran <shankare at codeaurora.org>wrote:

> Hi Nick, Bigcheese,
>
> When lld is used to link C++ code, it would be required to demangle symbol
> names by default/user driven option.
>
> The Gnu linker has the following options :-
>
> --demangle=[style]
> --no-demangle
>
> I found that clang/llvm-symbolizer use __cxx_demangle function.
>
> I would think that lld also need to call the same function, and I think
> the way we want to demangle is to have the function in LinkingContext as
> various flavors may choose to use different API's to demangle symbol names.
>
> 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
>

I wouldn't add canDemangle, but instead add "virtual std::string
demangle(StringRef symbolName)" with the default implementation that
returns a given string as is. Override the function if you want to support
demangling. Do nothing if you don't.

With this approach you can simply call demangle() unconditionally. If you
are lucky you'll get a demangled symbol name, and if not, you'll get a
fallback string.

Thoughts / Suggestions ?
>
> Thanks
>
> Shankar Easwaran
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
> by the Linux Foundation
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140401/7e633f6c/attachment.html>