[lld] [lld][symbol-ordering] Strip out llvm suffixes for orderfile (PR #102458)

[Egor Pasko via llvm-commits]

https://github.com/pasko created https://github.com/llvm/llvm-project/pull/102458

When Chrome DSO on Android is built with ThinLTO a large number of symbols acquire unique suffixes. A renamed symbol looks like this:
```
_ZL13_uhash_removeP10UHashtable8UElement.llvm.4477738147604602593
```

This makes it difficult to provide a precise --symbol-ordering-file because the build does not have control over these unique names.

One workaround is to rebuild with symbol ordering file after inspecting symbols in the first build. Chrome build infrastructure does not scale well when it has to deal with such additional build steps. It also significantly increases build times for release binaries, mostly doing duplicate work.

Instead, remove such suffix from each symbol before matching it against the ordering file.

Similar stripping is done in FunctionSamples::getCanonicalFnName().

This should help fixing http://crbug.com/356360613.

>From b89ed0ffd16e3b42fc1622e3791fd4e8a5d60769 Mon Sep 17 00:00:00 2001
From: Egor Pasko <pasko at chromium.org>
Date: Thu, 8 Aug 2024 14:07:55 +0200
Subject: [PATCH] [lld][symbol-ordering] Strip out llvm suffixes for orderfile

When Chrome DSO on Android is built with ThinLTO a large number of
symbols acquire unique suffixes. A renamed symbol looks like this:
```
_ZL13_uhash_removeP10UHashtable8UElement.llvm.4477738147604602593
```

This makes it difficult to provide a precise --symbol-ordering-file
because the build does not have control over these unique names.

One workaround is to rebuild with symbol ordering file after inspecting
symbols in the first build. Chrome build infrastructure does not scale
well when it has to deal with such additional build steps. It also
significantly increases build times for release binaries, mostly doing
duplicate work.

Instead, remove such suffix from each symbol before matching it against
the ordering file.

Similar stripping is done in FunctionSamples::getCanonicalFnName().

This should help fixing http://crbug.com/356360613.
---
 lld/ELF/Writer.cpp | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/lld/ELF/Writer.cpp b/lld/ELF/Writer.cpp
index 4c0b4df5bea170..08bafd85f1e98a 100644
--- a/lld/ELF/Writer.cpp
+++ b/lld/ELF/Writer.cpp
@@ -1061,6 +1061,20 @@ static void maybeShuffle(DenseMap<const InputSectionBase *, int> &order) {
   }
 }
 
+/// Indicator of a suffix inserted by LTO. Each symbol is matched against the
+/// symbol ordering file after stripping out such a suffix. This is similar to
+/// canonicalization in SampleProf.h.
+static constexpr const char *LLVMSuffix = ".llvm.";
+
+// Strips out suffixes commonly added by optimization passes.
+static StringRef getCanonicalSymbolName(StringRef symbolName) {
+  StringRef ret(symbolName);
+  auto it = ret.rfind(LLVMSuffix);
+  if (it != StringRef::npos)
+    ret = ret.substr(0, it);
+  return ret;
+}
+
 // Builds section order for handling --symbol-ordering-file.
 static DenseMap<const InputSectionBase *, int> buildSectionOrder() {
   DenseMap<const InputSectionBase *, int> sectionOrder;
@@ -1086,7 +1100,8 @@ static DenseMap<const InputSectionBase *, int> buildSectionOrder() {
 
   // Build a map from sections to their priorities.
   auto addSym = [&](Symbol &sym) {
-    auto it = symbolOrder.find(CachedHashStringRef(sym.getName()));
+    auto it = symbolOrder.find(
+        CachedHashStringRef(getCanonicalSymbolName(sym.getName())));
     if (it == symbolOrder.end())
       return;
     SymbolOrderEntry &ent = it->second;