mirror of
https://github.com/llvm/llvm-project.git
synced 2025-04-17 03:56:42 +00:00
4a4a8a1476
When LLD links against an import library (for the regular, short import libraries), it doesn't actually link in the header/trailer object files at all, but synthesizes new corresponding data structures into the right sections. If the whole of such an import library is forced to be linked, e.g. with the -wholearchive: option, we actually end up linking in those header/trailer objects. The header objects contain a construct which LLD fails to handle; previously we'd error out with the error ".idata$4 should not refer to special section 0". Within the import library header object, in the import directory we have relocations towards the IAT (.idata$4 and .idata$5), but the header object itself doesn't contain any data for those sections. In the case of GNU generated import libraries, the header objects contain zero length sections .idata$4 and .idata$5, with relocations against them. However in the case of LLVM generated import libraries, the sections .idata$4 and .idata$5 are not included in the list of sections. The symbol table does contain section symbols for these sections, but without any actual associated section. This can probably be seen as a declaration of an empty section. If the header/trailer objects of a short import library are linked forcibly and we also reference other functions in the library, we end up with two import directory entries for this DLL, one that gets synthesized by LLD, and one from the actual header object file. This is inelegant, but should be acceptable. While it would seem unusual to link import libraries with the -wholearchive: option, this can happen in certain scenarios. Rust builds libraries that contain relevant import libraries bundled along with compiled Rust code as regular object files, all within one single archive. Such an archive can then end up linked with the -wholarchive: option, if build systems decide to use such an option for including static libraries. This should fix https://github.com/msys2/MINGW-packages/issues/21017. This works for the header/trailer object files in import libraries generated by LLVM; import libraries generated by MSVC are vaguely different. ecb5ea6a266d5cc4e05252f6db4c73613b73cc3b did an attempt at fixing the issue for MSVC generated libraries, but it's not entirely correct, and isn't enough for making things work for that case.
36 lines
1.0 KiB
ArmAsm
36 lines
1.0 KiB
ArmAsm
// REQUIRES: x86
|
|
// RUN: split-file %s %t.dir
|
|
// RUN: llvm-lib -machine:amd64 -out:%t.lib -def:%t.dir/lib.def
|
|
// RUN: llvm-mc -filetype=obj -triple=x86_64-windows %t.dir/main.s -o %t.main.obj
|
|
|
|
// RUN: lld-link -out:%t.exe %t.main.obj -wholearchive:%t.lib -entry:entry -subsystem:console
|
|
// RUN: llvm-readobj --coff-imports %t.exe | FileCheck %s
|
|
|
|
// As LLD usually doesn't use the header/trailer object files from import
|
|
// libraries, but instead synthesizes those structures, we end up with two
|
|
// import directory entries if we force those objects to be included.
|
|
|
|
// CHECK: Import {
|
|
// CHECK-NEXT: Name: lib.dll
|
|
// CHECK-NEXT: ImportLookupTableRVA: 0x2050
|
|
// CHECK-NEXT: ImportAddressTableRVA: 0x2068
|
|
// CHECK-NEXT: }
|
|
// CHECK-NEXT: Import {
|
|
// CHECK-NEXT: Name: lib.dll
|
|
// CHECK-NEXT: ImportLookupTableRVA: 0x2058
|
|
// CHECK-NEXT: ImportAddressTableRVA: 0x2070
|
|
// CHECK-NEXT: Symbol: func (0)
|
|
// CHECK-NEXT: }
|
|
|
|
|
|
#--- main.s
|
|
.global entry
|
|
entry:
|
|
call func
|
|
ret
|
|
|
|
#--- lib.def
|
|
LIBRARY lib.dll
|
|
EXPORTS
|
|
func
|