<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>
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 ?</blockquote><div><br></div><div>First, it's really easy to detect which ABI is being used based on the prefix:</div>
<div>_Z -> standard Itanium demangler (__cxa_demangle)</div><div>__Z -> Itanium with a leading _</div><div>? -> MSVC</div><div><br></div><div>We don't need a virtual method. MinGW people might be linking Itanium symbols on Windows, and that should demangle just fine if __cxa_demangle is available.</div>
<div><br></div><div>Second, __cxa_demangle is not available on all platforms, so lld should just test for it's availability and use it for Itanium symbols if available.</div><div><br></div><div>I think the LLVM project has a demangler floating around (libc++?). It might be nice to find a way to reuse that across projects like this so the output of LLVM tools doesn't change based on the capabilities of the host. In other words, it'd be nice if we had a good story for demangled diagnostics while cross-linking.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
<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>
...<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="im HOEnZb"><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="HOEnZb"><div class="h5">
______________________________<u></u>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div></div>