[PATCH] D101569: [LLD] [COFF] Fix automatic export of symbols from LTO objects

Martin Storsjö via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Apr 29 13:51:46 PDT 2021


mstorsjo added inline comments.


================
Comment at: lld/COFF/Driver.cpp:1212
+    auto *defReg = dyn_cast<DefinedRegular>(s);
+    if (!defReg || defReg->data) {
+      if (Chunk *c = def->getChunk())
----------------
It turns out we can't actually call `def->getChunk()` on a `DefinedRegular` from a bitcode object file, because that symbol has got the `SectionChunk **data;` member set to `nullptr`, and `getChunk()` dereferences `*data`, so we have to do this dance so we won't crash on calling `def->getChunk()`.


================
Comment at: lld/COFF/Driver.cpp:1221
+          if (objSym.getName() == e.name) {
+            if (!objSym.isExecutable())
+              e.data = true;
----------------
Here we end up iterating over all symbols in the input bitcode file, to find the one we're looking at, to figure out whether it's data or a function. Not pretty...


================
Comment at: lld/COFF/Driver.cpp:2130
+    // are chosen to be exported.
+    maybeExportMinGWSymbols(args);
+  }
----------------
Here we need to decide what symbols to export before we run `addCombinedLTOObjects()`.


================
Comment at: lld/COFF/MinGW.cpp:126
 bool AutoExporter::shouldExport(Defined *sym) const {
-  if (!sym || !sym->getChunk())
     return false;
----------------
The `->getChunk()`  call from here stemmed from the original iplementation of this feature, where it was added just as a guesstimate of what would be a decent condition - for LTO symbols we must tolerate quite different symbols.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101569/new/

https://reviews.llvm.org/D101569



More information about the llvm-commits mailing list