[LLVMdev] [lld] adding demangler for symbol resolution

[Rui Ueyama]

On Wed, Apr 2, 2014 at 11:02 AM, Shankar Easwaran
<shankare at codeaurora.org>wrote:

> On 4/2/2014 12:23 PM, Nick Kledzik wrote:
>
>> On Apr 1, 2014, at 9:19 PM, Shankar Easwaran 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
>>>
>>> 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 ?
>
> 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 ?
>
>
>  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.
>
> As part of this, I was thinking to cleanup the way the errors are
> displayed to the user from the Resolver, we could have functions in
> SymbolTable with
>
> raiseError(SymbolErrorKind, filename, symbolname)
> raiseError(SymbolErrorKind, filename, symbolname, filename, symbolname)
>
> SymbolErrorKind :=
>
> MultipleDefinition
> Undefined
> GroupError
> Note (for tracing)
> ...


I'd think error message outputs are a bit scattered in SymbolTable.cpp, but
defining enum values for it is too much. Let's not design too much. I'd
define a function for each error if there are multiple locations printing
the same error. Also this is a separate issue from demangling so we
shouldn't mix them.


>
>
>  Seems like a demangling utility might be something to add at the LLVM
>> level.  Either directly to raw_ostream or a wrapper like format().
>>
> I have browsed discussions in llvm related to this to move the demangler
> function which is housed in libcxx, and I dont think there is a plan to
> move that.
>
> I think the format() specifier would be one thing that would be useful,
> but I am not sure on how different linking contexts in lld, could route
> calls with a central format specifier.
>
> Can you share more info on this ?
>
>
> 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/20140402/6ea5aaed/attachment.html>