maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lld/test/elf/gotpcrel.test

23 lines
641 B
Plaintext
Raw Normal View History

[lld][LayoutPass] This commit fixes a problem in the Layoutpass by ordering atoms if they appear in the override list first and then looking at the way of ordering atoms in the default way. The fix also fixes issues with the sizes of the sections, that appear in the output properly too. The commit also adds a testcase(orderatoms-by-override.test) to test it and fixes all the other relevant testcases. llvm-svn: 181605
2013-05-11 00:44:02 +08:00
# This test checks that GOTPCREL entries are being handled properly
[lld][LinkingContext][ELF] Allow different output file types. This adds an option --output-filetype that can be set to either YAML/Native(case insensitive). The linker would create the outputs associated with the type specified by the user. Changes all the tests to use the new option. llvm-svn: 191183
2013-09-23 12:24:15 +08:00
RUN: lld -flavor gnu -target x86_64-linux -static -e main --output-filetype=yaml \
This is my Driver refactoring patch. The major changes are: 1) LinkerOptions has been merged into TargetInfo 2) LinkerInvocation has been merged into Driver 3) Drivers no longer convert arguments into an intermediate (core) argument list, but instead create a TargetInfo object and call setter methods on it. This is only how in-process linking would work. That is, you can programmatically set up a TargetInfo object which controls the linking. 4) Lots of tweaks to test suite to work with driver changes 5) Add the DarwinDriver 6) I heavily doxygen commented TargetInfo.h Things to do after this patch is committed: a) Consider renaming TargetInfo, given its new roll. b) Consider pulling the list of input files out of TargetInfo. This will enable in-process clients to create one TargetInfo the re-use it with different input file lists. c) Work out a way for Drivers to format the warnings and error done in core linking. llvm-svn: 178776
2013-04-05 02:59:24 +08:00
RUN: --noinhibit-exec %p/Inputs/gotpcrel.x86-64 \
RUN: | FileCheck %s -check-prefix=YAML
[ELF][x86-64] Implement static relocation model for TLS. This implements the static relocation model for GOT accesses to TLS. llvm-svn: 174155
2013-02-01 15:14:14 +08:00
[lld][LayoutPass] Order the atoms that are in the same chain We need to order atoms that exist in the same chain. This is to make sure that the command line order is preserved when we emit the atoms to the output file. Credits: BigCheese for finding the bug. Adds a test which otherwise would fail. llvm-svn: 190608
2013-09-12 23:43:09 +08:00
YAML: name: [[NULLGOT:[a-zA-Z0-9_]+]]
YAML: content: [ 00, 00, 00, 00, 00, 00, 00, 00 ]
YAML-NOT: references:
YAML: name: [[MAINGOT:[a-zA-Z0-9_]+]]
YAML: kind: R_X86_64_64
YAML: target: main
[ELF][x86-64] Separate static and dynamic GOT/PLT generation. llvm-svn: 176294
2013-03-01 04:04:32 +08:00
YAML: name: main
This is my Driver refactoring patch. The major changes are: 1) LinkerOptions has been merged into TargetInfo 2) LinkerInvocation has been merged into Driver 3) Drivers no longer convert arguments into an intermediate (core) argument list, but instead create a TargetInfo object and call setter methods on it. This is only how in-process linking would work. That is, you can programmatically set up a TargetInfo object which controls the linking. 4) Lots of tweaks to test suite to work with driver changes 5) Add the DarwinDriver 6) I heavily doxygen commented TargetInfo.h Things to do after this patch is committed: a) Consider renaming TargetInfo, given its new roll. b) Consider pulling the list of input files out of TargetInfo. This will enable in-process clients to create one TargetInfo the re-use it with different input file lists. c) Work out a way for Drivers to format the warnings and error done in core linking. llvm-svn: 178776
2013-04-05 02:59:24 +08:00
YAML: references:
YAML: kind: R_X86_64_PC32
YAML: offset: 3
[lld][LayoutPass] Order the atoms that are in the same chain We need to order atoms that exist in the same chain. This is to make sure that the command line order is preserved when we emit the atoms to the output file. Credits: BigCheese for finding the bug. Adds a test which otherwise would fail. llvm-svn: 190608
2013-09-12 23:43:09 +08:00
YAML: target: [[NULLGOT]]
This is my Driver refactoring patch. The major changes are: 1) LinkerOptions has been merged into TargetInfo 2) LinkerInvocation has been merged into Driver 3) Drivers no longer convert arguments into an intermediate (core) argument list, but instead create a TargetInfo object and call setter methods on it. This is only how in-process linking would work. That is, you can programmatically set up a TargetInfo object which controls the linking. 4) Lots of tweaks to test suite to work with driver changes 5) Add the DarwinDriver 6) I heavily doxygen commented TargetInfo.h Things to do after this patch is committed: a) Consider renaming TargetInfo, given its new roll. b) Consider pulling the list of input files out of TargetInfo. This will enable in-process clients to create one TargetInfo the re-use it with different input file lists. c) Work out a way for Drivers to format the warnings and error done in core linking. llvm-svn: 178776
2013-04-05 02:59:24 +08:00
YAML: kind: R_X86_64_PC32
YAML: offset: 10
[lld][LayoutPass] Order the atoms that are in the same chain We need to order atoms that exist in the same chain. This is to make sure that the command line order is preserved when we emit the atoms to the output file. Credits: BigCheese for finding the bug. Adds a test which otherwise would fail. llvm-svn: 190608
2013-09-12 23:43:09 +08:00
YAML: target: [[MAINGOT]]
This is my Driver refactoring patch. The major changes are: 1) LinkerOptions has been merged into TargetInfo 2) LinkerInvocation has been merged into Driver 3) Drivers no longer convert arguments into an intermediate (core) argument list, but instead create a TargetInfo object and call setter methods on it. This is only how in-process linking would work. That is, you can programmatically set up a TargetInfo object which controls the linking. 4) Lots of tweaks to test suite to work with driver changes 5) Add the DarwinDriver 6) I heavily doxygen commented TargetInfo.h Things to do after this patch is committed: a) Consider renaming TargetInfo, given its new roll. b) Consider pulling the list of input files out of TargetInfo. This will enable in-process clients to create one TargetInfo the re-use it with different input file lists. c) Work out a way for Drivers to format the warnings and error done in core linking. llvm-svn: 178776
2013-04-05 02:59:24 +08:00