maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lld/test/COFF/link-dll-i386.s

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

65 lines
1.5 KiB
ArmAsm
Raw Normal View History

[LLD] [COFF] Support linking directly against DLLs in MinGW mode GNU ld.bfd supports linking directly against DLLs without using an import library, and some projects have picked up on this habit. (There's no one single unsurmountable issue with using import libraries, but this is a regularly surfacing missing feature.) As long as one is linking by name (instead of by ordinal), the DLL export table contains most of the information needed. (One can inspect what section a symbol points at, to see if it's a function or data symbol. The practical implementation of this loops over all sections for each symbol, but as long as they're not very many, that should hopefully be tolerable performance wise.) One exception where the information in the DLL isn't entirely enough is on i386 with stdcall functions; depending on how they're done, the exported function name can be a plain undecorated name, while the import library would contain the full decorated symbol name. This issue is addressed separately in a different patch. This is implemented mimicing the structure of a regular import library, with one InputFile corresponding to the static archive that just adds lazy symbols, which then are fetched when they are needed. When such a symbol is fetched, we synthesize a coff_import_header structure in memory and create a regular ImportFile out of it. The implementation could be even smaller by just creating ImportFiles for every symbol available immediately, but that would have the drawback of actually ending up importing all symbols unless running with GC enabled (and mingw mode defaults to having it disabled for historical reasons). Differential Revision: https://reviews.llvm.org/D104530
2021-06-16 21:59:46 +08:00
# REQUIRES: x86
## Test creating a DLL and linking against the DLL without using an import
## library.
## Test on i386 with cdecl decorated symbols.
## Linking the executable with -opt:noref, to make sure that we don't
## pull in more import entries than what's needed, even if not running GC.
# RUN: split-file %s %t.dir
# RUN: llvm-mc -filetype=obj -triple=i386-windows-gnu %t.dir/lib.s -o %t.lib.o
# RUN: lld-link -safeseh:no -noentry -dll -def:%t.dir/lib.def %t.lib.o -out:%t.lib.dll -implib:%t.implib.lib
# RUN: llvm-mc -filetype=obj -triple=i386-windows-gnu %t.dir/main.s -o %t.main.o
# RUN: lld-link -lldmingw %t.main.o -out:%t.main.exe %t.lib.dll -opt:noref -verbose 2>&1 | FileCheck --check-prefix=LOG %s
# RUN: llvm-readobj --coff-imports %t.main.exe | FileCheck %s
#--- lib.s
.text
.global _func1
_func1:
ret
.global _func2
_func2:
ret
.global _func3
_func3:
ret
.data
.global _variable
_variable:
.int 42
#--- lib.def
EXPORTS
func1
func2
func3
variable
#--- main.s
.text
.global _mainCRTStartup
_mainCRTStartup:
call _func2
movl .refptr._variable, %eax
movl (%eax), %eax
ret
.section .rdata$.refptr._variable,"dr",discard,.refptr._variable
.globl .refptr._variable
.refptr._variable:
.long _variable
# CHECK: Import {
# CHECK-NEXT: Name: link-dll-i386.s.tmp.lib.dll
# CHECK-NEXT: ImportLookupTableRVA:
# CHECK-NEXT: ImportAddressTableRVA
# CHECK-NEXT: Symbol: func2
# CHECK-NEXT: Symbol: variable
# CHECK-NEXT: }
# LOG: Automatically importing _variable from link-dll-i386.s.tmp.lib.dll