<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Apr 2, 2014 at 11:02 AM, Shankar Easwaran <span dir="ltr"><<a href="mailto:shankare@codeaurora.org" target="_blank">shankare@codeaurora.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 4/2/2014 12:23 PM, Nick Kledzik wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Apr 1, 2014, at 9:19 PM, Shankar Easwaran wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Nick, Bigcheese,<br>
<br>
When lld is used to link C++ code, it would be required to demangle symbol names by default/user driven option.<br>
<br>
The Gnu linker has the following options :-<br>
<br>
--demangle=[style]<br>
--no-demangle<br>
<br>
I found that clang/llvm-symbolizer use __cxx_demangle function.<br>
<br>
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.<br>


<br>
The API's that would be in LinkingContext would be :-<br>
<br>
        * virtual bool canDemangle()  = 0; // Does the flavor provide a way to demangle symbol names ?<br>
        * virtual std::string demangle(StringRef symbolName) = 0; // demangle the symbol name<br>
<br>
Thoughts / Suggestions ?<br>
</blockquote>
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.<br>


</blockquote></div>
Are you mentioning that one demangle function in LinkingContext ?<br>
<br>
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 ?<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>


</blockquote></div>
I dont know if diagnostics in clang, already redirect things directly to a stream.<br>
<br>
May be for now, as an initial implementation, we can have a single demangle function that returns a std::string.<br>
<br>
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<br>
<br>
raiseError(SymbolErrorKind, filename, symbolname)<br>
raiseError(SymbolErrorKind, filename, symbolname, filename, symbolname)<br>
<br>
SymbolErrorKind :=<br>
<br>
MultipleDefinition<br>
Undefined<br>
GroupError<br>
Note (for tracing)<br>
...</blockquote><div><br></div><div>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.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Seems like a demangling utility might be something to add at the LLVM level.  Either directly to raw_ostream or a wrapper like format().<br>
</blockquote></div>
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.<br>
<br>
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.<br>
<br>
Can you share more info on this ?<div class="HOEnZb"><div class="h5"><br>
<br>
Thanks<br>
<br>
Shankar Easwaran<br>
<br>
-- <br>
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation<br>
<br>
</div><div class="h5"><br></div></div></blockquote></div></div></div>