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/order.test

16 lines
554 B
Plaintext
Raw Normal View History

COFF: Make link order compatible with MSVC link.exe. Previously, we added files in directive sections to the symbol table as we read the sections, so the link order was depth-first. That's not compatible with MSVC link.exe nor the old LLD. This patch is to queue files so that new files are added to the end of the queue and processed last. Now addFile() doesn't parse files nor resolve symbols. You need to call run() to process queued files. llvm-svn: 240483
2015-06-24 07:56:39 +08:00
# RUN: yaml2obj < %p/Inputs/include1a.yaml > %t1.obj
# RUN: yaml2obj < %p/Inputs/include1b.yaml > %t2.obj
# RUN: yaml2obj < %p/Inputs/include1c.yaml > %t3.obj
# RUN: rm -f %t2.lib %t3.lib
# RUN: llvm-ar cru %t2.lib %t2.obj
# RUN: llvm-ar cru %t3.lib %t3.obj
COFF: Make test commands shorter. NFC. llvm-svn: 244227
2015-08-07 00:47:46 +08:00
# RUN: lld-link /out:%t.exe /entry:main \
COFF: Fix logic to find default entry name or subsystem. The previous logic to find default entry name or subsystem does not seem correct (i.e. was not compatible with MSVC linker). Previously, default entry name was inferred from CRT functions and user-defined entry functions. Subsystem was inferred from CRT functions. Default entry name and subsystem are now inferred based on the following table. Note that we no longer use CRT functions to infer them. Entry name Subsystem main mainCRTStartup console wmain wmainCRTStartup console WinMain WinMainCRTStartup windows wWinMain wWinMainCRTStartup windows llvm-svn: 240922
2015-06-29 09:03:53 +08:00
# RUN: %t1.obj %t2.lib %t3.obj %t3.lib /verbose >& %t.log
COFF: Make link order compatible with MSVC link.exe. Previously, we added files in directive sections to the symbol table as we read the sections, so the link order was depth-first. That's not compatible with MSVC link.exe nor the old LLD. This patch is to queue files so that new files are added to the end of the queue and processed last. Now addFile() doesn't parse files nor resolve symbols. You need to call run() to process queued files. llvm-svn: 240483
2015-06-24 07:56:39 +08:00
# RUN: FileCheck %s < %t.log
CHECK: order.test.tmp1.obj
CHECK: order.test.tmp3.obj
COFF: Change the order of adding symbols to the symbol table. Previously, the order of adding symbols to the symbol table was simple. We have a list of all input files. We read each file from beginning of the list and add all symbols in it to the symbol table. This patch changes that order. Now all archive files are added to the symbol table first, and then all the other object files are added. This shouldn't change the behavior in single-threading, and make room to parallelize in multi-threading. In the first step, only lazy symbols are added to the symbol table because archives contain only Lazy symbols. Member object files found to be necessary are queued. In the second step, defined and undefined symbols are added from object files. Adding an undefined symbol to the symbol table may cause more member files to be added to the queue. We simply continue reading all object files until the queue is empty. Finally, new archive or object files may be added to the queues by object files' directive sections (which contain new command line options). The above process is repeated until we get no new files. Symbols defined both in object files and in archives can make results undeterministic. If an archive is read before an object, a new member file gets linked, while in the other way, no new file would be added. That is the most popular cause of an undeterministic result or linking failure as I observed. Separating phases of adding lazy symbols and undefined symbols makes that deterministic. Adding symbols in each phase should be parallelizable. llvm-svn: 241107
2015-07-01 03:35:21 +08:00
CHECK: order.test.tmp2.lib
COFF: Make link order compatible with MSVC link.exe. Previously, we added files in directive sections to the symbol table as we read the sections, so the link order was depth-first. That's not compatible with MSVC link.exe nor the old LLD. This patch is to queue files so that new files are added to the end of the queue and processed last. Now addFile() doesn't parse files nor resolve symbols. You need to call run() to process queued files. llvm-svn: 240483
2015-06-24 07:56:39 +08:00
CHECK: order.test.tmp3.lib
COFF: Change the order of adding symbols to the symbol table. Previously, the order of adding symbols to the symbol table was simple. We have a list of all input files. We read each file from beginning of the list and add all symbols in it to the symbol table. This patch changes that order. Now all archive files are added to the symbol table first, and then all the other object files are added. This shouldn't change the behavior in single-threading, and make room to parallelize in multi-threading. In the first step, only lazy symbols are added to the symbol table because archives contain only Lazy symbols. Member object files found to be necessary are queued. In the second step, defined and undefined symbols are added from object files. Adding an undefined symbol to the symbol table may cause more member files to be added to the queue. We simply continue reading all object files until the queue is empty. Finally, new archive or object files may be added to the queues by object files' directive sections (which contain new command line options). The above process is repeated until we get no new files. Symbols defined both in object files and in archives can make results undeterministic. If an archive is read before an object, a new member file gets linked, while in the other way, no new file would be added. That is the most popular cause of an undeterministic result or linking failure as I observed. Separating phases of adding lazy symbols and undefined symbols makes that deterministic. Adding symbols in each phase should be parallelizable. llvm-svn: 241107
2015-07-01 03:35:21 +08:00
CHECK: order.test.tmp2.lib(order.test.tmp2.obj) for foo