[PATCH] D150339: [BOLT] Fix state of MCSymbols in lowering pass

[Rafael Auler via Phabricator via llvm-commits]

rafauler created this revision.
rafauler added a reviewer: bolt.
Herald added subscribers: treapster, ayermolo, kristof.beyls.
Herald added a reviewer: Amir.
Herald added a reviewer: maksfb.
Herald added a project: All.
rafauler requested review of this revision.
Herald added subscribers: llvm-commits, yota9.
Herald added a project: LLVM.

We have mostly harmless data races when running
BinaryContext::calculateEmittedSize() in parallel, while performing
split function pass.  However, it is possible to end up in a state
where some MCSymbols are still registered and our clean up
failed. This happens rarely but it does happen, and when it happens,
it is a difficult to diagnose heisenbug. To avoid this, change our
lowering pass to perform a last check on MCSymbols, before they
undergo our final emission pass, to verify that they are in a sane
state. If we fail to do this, we might resolve some symbols to zero
and crash the output binary.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D150339

Files:
  bolt/include/bolt/Passes/BinaryPasses.h
  bolt/lib/Passes/BinaryPasses.cpp
  bolt/lib/Rewrite/BinaryPassManager.cpp


Index: bolt/lib/Rewrite/BinaryPassManager.cpp
===================================================================
--- bolt/lib/Rewrite/BinaryPassManager.cpp
+++ bolt/lib/Rewrite/BinaryPassManager.cpp
@@ -488,6 +488,10 @@
 
   Manager.registerPass(std::make_unique<LowerAnnotations>(NeverPrint));
 
+  // Check for dirty state of MCSymbols caused by running calculateEmittedSize
+  // in parallel and restore them
+  Manager.registerPass(std::make_unique<CleanMCState>(NeverPrint));
+
   Manager.runPasses();
 }
 
Index: bolt/lib/Passes/BinaryPasses.cpp
===================================================================
--- bolt/lib/Passes/BinaryPasses.cpp
+++ bolt/lib/Passes/BinaryPasses.cpp
@@ -626,6 +626,30 @@
     BC.MIB->setOffset(*Item.first, Item.second);
 }
 
+// Check for dirty state in MCSymbol objects that might be a consequence
+// of running calculateEmittedSize() in parallel, during split functions
+// pass. If an inconsistent state is found (symbol already registered or
+// already defined), clean it.
+void CleanMCState::runOnFunctions(BinaryContext &BC) {
+  MCContext &Ctx = *BC.Ctx;
+  for (const auto &SymMapEntry : Ctx.getSymbols()) {
+    const MCSymbol *S = SymMapEntry.second;
+    if (S->isDefined()) {
+      LLVM_DEBUG(dbgs() << "BOLT-DEBUG: Symbol \"" << S->getName()
+                        << "\" is already defined\n");
+      const_cast<MCSymbol *>(S)->setUndefined();
+    }
+    if (S->isRegistered()) {
+      LLVM_DEBUG(dbgs() << "BOLT-DEBUG: Symbol \"" << S->getName()
+                        << "\" is already registered\n");
+      const_cast<MCSymbol *>(S)->setIsRegistered(false);
+    }
+    LLVM_DEBUG(if (S->isVariable()) {
+      dbgs() << "BOLT-DEBUG: Symbol \"" << S->getName() << "\" is variable\n";
+    });
+  }
+}
+
 // This peephole fixes jump instructions that jump to another basic
 // block with a single jump instruction, e.g.
 //
Index: bolt/include/bolt/Passes/BinaryPasses.h
===================================================================
--- bolt/include/bolt/Passes/BinaryPasses.h
+++ bolt/include/bolt/Passes/BinaryPasses.h
@@ -213,6 +213,17 @@
   void runOnFunctions(BinaryContext &BC) override;
 };
 
+/// Clean the state of the MC representation before sending it to emission
+class CleanMCState : public BinaryFunctionPass {
+public:
+  explicit CleanMCState(const cl::opt<bool> &PrintPass)
+      : BinaryFunctionPass(PrintPass) {}
+
+  const char *getName() const override { return "clean-mc-state"; }
+  void runOnFunctions(BinaryContext &BC) override;
+};
+
+
 /// An optimization to simplify conditional tail calls by removing
 /// unnecessary branches.
 ///


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D150339.521191.patch
Type: text/x-patch
Size: 2644 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20230511/c4834e9f/attachment.bin>