<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 14, 2015 at 12:44 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Adding llvm-dev as that might be a more suitable audience for this discussion.<br><br>(& I know Lang's been playing around with the same problem in the Orc JIT, so adding him too)<br><br>Is there any basis/reason to believe that the .X suffix is a better, more principled one than straight X? Is that documented somewhere as a thing the demangling tools will ignore?</div></blockquote><div><br></div><div>At least for the Itanium ABI, it's possible for both ${foo} and ${foo}1 to be valid mangled names, so a demangler isn't able to ignore our current suffixes even in theory. Not an argument for .X, but it's an argument against plain X.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">On Tue, Apr 14, 2015 at 12:06 PM, Srivastava, Sunil <span dir="ltr"><<a href="mailto:sunil_srivastava@playstation.sony.com" target="_blank">sunil_srivastava@playstation.sony.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
<div lang="EN-US" link="#0563C1" vlink="#954F72">
<div>
<p class="MsoNormal">Hi,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">We are running into a problem created by renaming of static symbols by llvm-link. It first
<u></u><u></u></p>
<p class="MsoNormal">showed up using LTO, but we can illustrate this by using llvm-link as well.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Say we have two files with the same named static symbol Bye<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">--------------- t1.cpp ---------<u></u><u></u></p>
<p class="MsoNormal">static void Bye(int* ba1) { ba1[0] /= ba1[2] - 2; }<u></u><u></u></p>
<p class="MsoNormal">void main_a( int* inB) { void (*func)(int*) = Bye; func(inB); }<u></u><u></u></p>
<p class="MsoNormal">--------------- t2.cpp ---------<u></u><u></u></p>
<p class="MsoNormal">static void Bye(int* ba1) { ba1[0] *= ba1[2] + 2; }<u></u><u></u></p>
<p class="MsoNormal">void main_b( int* inB) { void (*func)(int*) = Bye; func(inB+1); }<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">--------- cmd sequence -------<u></u><u></u></p>
<p class="MsoNormal">$ clang++ -c -emit-llvm t1.cpp -o t1.bc<u></u><u></u></p>
<p class="MsoNormal">$ clang++ -c -emit-llvm t1.cpp -o t2.bc<u></u><u></u></p>
<p class="MsoNormal">$ llvm-link t1.bc t2.bc -o t23.bc<u></u><u></u></p>
<p class="MsoNormal">$ clang -c t23.bc<u></u><u></u></p>
<p class="MsoNormal">$ nm t23.o<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">t1.o and t2.o have the same named function “_ZL3ByePi”. In order to distinguish them,
<u></u><u></u></p>
<p class="MsoNormal">one gets a ‘1’ appended to it, making it “_ZL3ByePi1”.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">While the code is all correct, the problem is that this modified name cannot be demangled.
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">That is what I am trying to fix. <u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">In similar situations gcc appends a ‘.’ before appending the discriminating number, making “_ZL3ByePi.1”<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">The following change in lib/IR/ValueSymbolTable.cpp seems to fix this problem.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">------------ start diff -------------------<u></u><u></u></p>
<p class="MsoNormal">@@ -54,5 +54,5 @@ void ValueSymbolTable::reinsertValue(Value* V) {<u></u><u></u></p>
<p class="MsoNormal"> // Trim any suffix off and append the next number.<u></u><u></u></p>
<p class="MsoNormal"> UniqueName.resize(BaseSize);<u></u><u></u></p>
<p class="MsoNormal">- raw_svector_ostream(UniqueName) << ++LastUnique;<u></u><u></u></p>
<p class="MsoNormal">+ raw_svector_ostream(UniqueName) << "." << ++LastUnique;<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"> // Try insert the vmap entry with this suffix.<u></u><u></u></p>
<p class="MsoNormal">-------------- end diff ---------------------<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">However it causes 60 test failures. These are tests where some names that are expecting
<u></u><u></u></p>
<p class="MsoNormal">to get a plain numeric suffix now have a ‘.’ before it. These are all local symbols, so I think<u></u><u></u></p>
<p class="MsoNormal">the generated code will always be correct, but the tests as written do not pass. For
<u></u><u></u></p>
<p class="MsoNormal">example, take test/CodeGen/ARM/global-merge-addrspace.ll<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">; RUN: llc < %s -mtriple=thumb-apple-darwin -O3 | FileCheck %s<u></u><u></u></p>
<p class="MsoNormal">; Test the GlobalMerge pass. Check that the pass does not crash when using<u></u><u></u></p>
<p class="MsoNormal">; multiple address spaces.<u></u><u></u></p>
<p class="MsoNormal">; CHECK: _MergedGlobals:<u></u><u></u></p>
<p class="MsoNormal">@g1 = internal addrspace(1) global i32 1<u></u><u></u></p>
<p class="MsoNormal">@g2 = internal addrspace(1) global i32 2<u></u><u></u></p>
<p class="MsoNormal">; CHECK: _MergedGlobals1:<u></u><u></u></p>
<p class="MsoNormal">@g3 = internal addrspace(2) global i32 3<u></u><u></u></p>
<p class="MsoNormal">@g4 = internal addrspace(2) global i32 4<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">With my change, the symbol is named MergedGlobals.1, hence it fails this test.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I could change these 60 tests to match the new behavior. That will fix these 60 failures.
<u></u><u></u></p>
<p class="MsoNormal">However, I do have a concern that there may be other places in llvm that expect the
<u></u><u></u></p>
<p class="MsoNormal">names to be pure identifiers. Adding a ‘.’ may cause them to fail. No such failure has been
<u></u><u></u></p>
<p class="MsoNormal">seen in running the whole clang test, but the concern is still there.
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I should note that even local symbols are treated similarly, so for example, a parameter
<u></u><u></u></p>
<p class="MsoNormal">named ‘str’ becomes ‘str.1’ with my change, instead of ‘str1’ currently (an actual
<u></u><u></u></p>
<p class="MsoNormal">example from a test).<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Alternatively, I could try to limit my change to just mangled names.
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Any suggestion about how this should be fixed ?<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">There is another similar change about 40 lines below in ValueSymbolTable::createValueName().
<u></u><u></u></p>
<p class="MsoNormal">That is not needed to fix this particular problem, but looks similar, so perhaps should be treated
<u></u><u></u></p>
<p class="MsoNormal">similarly for consistency. It causes 66 more failures of the same nature though.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thanks<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Sunil Srivastava<u></u><u></u></p>
<p class="MsoNormal">Sony Computer Entertainment<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<br></div></div>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">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/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div></div>