[PATCH] D104530: [LLD] [COFF] Support linking directly against DLLs in MinGW mode
Martin Storsjö via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Jul 1 14:37:54 PDT 2021
mstorsjo added inline comments.
================
Comment at: lld/COFF/InputFiles.cpp:1164
+ bool code = false;
+ for (size_t i = 1, e = coffObj->getNumberOfSections(); i <= e; i++) {
+ const coff_section *sec = CHECK(coffObj->getSection(i), this);
----------------
rnk wrote:
> Factoring out the computation of this boolean would help readability. Initially I thought "this should be a data structure", but there are so few PE sections that it really doesn't matter.
Yep; this does end up with something like O(n*m) efficiency too, but as the number of sections is only half a dozen normally, it's probably not a biggie.
I can split it out to a separate function.
================
Comment at: lld/COFF/InputFiles.cpp:1175-1178
+ s->dllName = dllName;
+ s->symbolName = symbolName;
+ s->importType = code ? ImportType::IMPORT_CODE : ImportType::IMPORT_DATA;
+ s->nameType = ImportNameType::IMPORT_NAME;
----------------
rnk wrote:
> Instead of copying these strings into a newly allocated data structure, is there some way to put the export directory index into the LazyDLLSymbol? Most of the fields of DLLFile::Symbol seem like they can be calculated later after symbol resolution. This would avoid copying all the exported strings once.
I iterated a bit back and forth on this while making the patch...
In practice, we actually do need most of the fields from the get go; we do need to know whether to insert the `__imp_`-less symbol into the symbol table (so we need to find the `bool code` for each symbol). Technically we don't need to store the original `symbolName` (for a data import), but once we synthesize the import struct we do need the original `symbolName` again (and I'd prefer to avoid working with heuristics for stripping out `__imp_` from the symbol name when we can avoid it). The `dllName` isn't needed until the end, but a `StringRef` for it is pretty much as cheap as a reference to the COFFObjectFile for fetching it later, assuming the operation for fetching it isn't too costly.
Secondly, `ExportDirectoryEntryRef` is kinda opaque - it's a bit large in itself and it doesn't expose the index publicly. I did experiment with storing the whole `ExportDirectoryEntryRef` in `LazyDLLSymbol`, but I needed to have the `code` flag separately anyway, and then it exceeded the size for the symbol union.
So in practice, it feels a bit excessive to fetch all the info originally at first, but there's surprisingly little to shave off...
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D104530/new/
https://reviews.llvm.org/D104530
More information about the llvm-commits
mailing list