[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