We're seeing binutils ld produce binaries where the import address
table's NameRVA entry is actually a VA instead (i.e. it's already base
relocated), which llvm-readobj then chokes on. Both dumpbin and the
Windows loader are able to handle these binaries correctly, however, and
we can make llvm-readobj handle them correctly too by iterating the
import lookup table (which doesn't have a relocated NameRVA) rather than
the import address table.
The import lookup table and the import address table are supposed to be
identical on disk, and prior to r277298 the import lookup table would be
used by `llvm-readobj -coff-imports` anyway, so this shouldn't have any
functional change (except in the case of our malformed binaries). The
import lookup table can apparently be missing when using old Borland
linkers, so fall back to the import address table in that case.
Resolves PR31766.
Differential Revision: https://reviews.llvm.org/D31362
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@298812
91177308-0d34-0410-b5e6-
96231b3b80d8
StringRef Name;
error(I.getName(Name));
W.printString("Name", Name);
- uint32_t Addr;
- error(I.getImportLookupTableRVA(Addr));
- W.printHex("ImportLookupTableRVA", Addr);
- error(I.getImportAddressTableRVA(Addr));
- W.printHex("ImportAddressTableRVA", Addr);
- printImportedSymbols(I.imported_symbols());
+ uint32_t ILTAddr;
+ error(I.getImportLookupTableRVA(ILTAddr));
+ W.printHex("ImportLookupTableRVA", ILTAddr);
+ uint32_t IATAddr;
+ error(I.getImportAddressTableRVA(IATAddr));
+ W.printHex("ImportAddressTableRVA", IATAddr);
+ // The import lookup table can be missing with certain older linkers, so
+ // fall back to the import address table in that case.
+ if (ILTAddr)
+ printImportedSymbols(I.lookup_table_symbols());
+ else
+ printImportedSymbols(I.imported_symbols());
}
// Delay imports