replica
/
hanchenye-llvm-project
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
hanchenye-llvm-project/lld/test/old-elf/reloc.test

39 lines
1.6 KiB
Plaintext
Raw Normal View History

Rename the gnu flavour to gnu old. This is the first step in making ELF2 the default. llvm-svn: 253188
2015-11-16 16:54:19 +08:00
RUN: lld -flavor old-gnu -target i386 --merge-strings -r --output-filetype=yaml \
[ELF] Add missing -target options. These tests assume that the created objects are for x86_64. These tests failed on non-x86_64 environments, such as 32 bit Windows. llvm-svn: 193910
2013-11-02 11:50:03 +08:00
RUN: %p/Inputs/reloc-test.elf-i386 | FileCheck %s -check-prefix ELF-i386
Add ELFReference class - parse relocations needed by that class and update DefinedAtom to use the class. Tweak coding style. Add testcase to check relocations. Change was signed-off-by: Michael Spencer llvm-svn: 164027
2012-09-17 20:49:38 +08:00
Fix trailing whitespace. llvm-svn: 200182
2014-01-27 11:09:26 +08:00
ELF-i386: defined-atoms:
[lld][ELF] reduce the number of symbols emitted in the symbol table llvm-svn: 180872
2013-05-02 03:36:38 +08:00
ELF-i386: - ref-name: [[STRNAMEA:[-a-zA-Z0-9_]+]]
add support for merging common strings llvm-svn: 174990
2013-02-13 02:46:53 +08:00
ELF-i386: type: constant
ELF-i386: content: [ 68, 65, 6C, 6C, 6F, 20, 77, 6F, 72, 6C, 64, 00 ]
ELF-i386: merge: by-content
[lld][ELF] reduce the number of symbols emitted in the symbol table llvm-svn: 180872
2013-05-02 03:36:38 +08:00
ELF-i386: - ref-name: [[STRNAMEB:[-a-zA-Z0-9_]+]]
YAML: Do not use 2^x notation to represent alignments. llvm-svn: 233222
2015-03-26 06:06:04 +08:00
ELF-i386: alignment: 16
[lld][ELF] reduce the number of symbols emitted in the symbol table llvm-svn: 180872
2013-05-02 03:36:38 +08:00
ELF-i386: section-choice: custom-required
ELF-i386: section-name: .text.startup
Fix trailing whitespace. llvm-svn: 200182
2014-01-27 11:09:26 +08:00
ELF-i386: references:
[lld][ELF] reduce the number of symbols emitted in the symbol table llvm-svn: 180872
2013-05-02 03:36:38 +08:00
ELF-i386: - kind: layout-after
ELF-i386: offset: 0
ELF-i386: target: main
add support for merging common strings llvm-svn: 174990
2013-02-13 02:46:53 +08:00
ELF-i386: - name: main
ELF-i386: scope: global
Fix trailing whitespace. llvm-svn: 200182
2014-01-27 11:09:26 +08:00
ELF-i386: content: [ 55, 89, E5, 83, E4, F0, 83, EC, 10, C7, 04, 24,
ELF-i386: 00, 00, 00, 00, E8, FC, FF, FF, FF, 31, C0, C9,
add support for merging common strings llvm-svn: 174990
2013-02-13 02:46:53 +08:00
ELF-i386: C3 ]
YAML: Do not use 2^x notation to represent alignments. llvm-svn: 233222
2015-03-26 06:06:04 +08:00
ELF-i386: alignment: 16
add support for merging common strings llvm-svn: 174990
2013-02-13 02:46:53 +08:00
ELF-i386: section-choice: custom-required
ELF-i386: section-name: .text.startup
Fix trailing whitespace. llvm-svn: 200182
2014-01-27 11:09:26 +08:00
ELF-i386: references:
[lld] Introduce registry and Reference kind tuple The main changes are in: include/lld/Core/Reference.h include/lld/ReaderWriter/Reader.h Everything else is details to support the main change. 1) Registration based Readers Previously, lld had a tangled interdependency with all the Readers. It would have been impossible to make a streamlined linker (say for a JIT) which just supported one file format and one architecture (no yaml, no archives, etc). The old model also required a LinkingContext to read an object file, which would have made .o inspection tools awkward. The new model is that there is a global Registry object. You programmatically register the Readers you want with the registry object. Whenever you need to read/parse a file, you ask the registry to do it, and the registry tries each registered reader. For ease of use with the existing lld code base, there is one Registry object inside the LinkingContext object. 2) Changing kind value to be a tuple Beside Readers, the registry also keeps track of the mapping for Reference Kind values to and from strings. Along with that, this patch also fixes an ambiguity with the previous Reference::Kind values. The problem was that we wanted to reuse existing relocation type values as Reference::Kind values. But then how can the YAML write know how to convert a value to a string? The fix is to change the 32-bit Reference::Kind into a tuple with an 8-bit namespace (e.g. ELF, COFFF, etc), an 8-bit architecture (e.g. x86_64, PowerPC, etc), and a 16-bit value. This tuple system allows conversion to and from strings with no ambiguities. llvm-svn: 197727
2013-12-20 05:58:00 +08:00
ELF-i386: - kind: R_386_32
add support for merging common strings llvm-svn: 174990
2013-02-13 02:46:53 +08:00
ELF-i386: offset: 12
[lld][ELF] reduce the number of symbols emitted in the symbol table llvm-svn: 180872
2013-05-02 03:36:38 +08:00
ELF-i386: target: [[STRNAMEA]]
[lld] Introduce registry and Reference kind tuple The main changes are in: include/lld/Core/Reference.h include/lld/ReaderWriter/Reader.h Everything else is details to support the main change. 1) Registration based Readers Previously, lld had a tangled interdependency with all the Readers. It would have been impossible to make a streamlined linker (say for a JIT) which just supported one file format and one architecture (no yaml, no archives, etc). The old model also required a LinkingContext to read an object file, which would have made .o inspection tools awkward. The new model is that there is a global Registry object. You programmatically register the Readers you want with the registry object. Whenever you need to read/parse a file, you ask the registry to do it, and the registry tries each registered reader. For ease of use with the existing lld code base, there is one Registry object inside the LinkingContext object. 2) Changing kind value to be a tuple Beside Readers, the registry also keeps track of the mapping for Reference Kind values to and from strings. Along with that, this patch also fixes an ambiguity with the previous Reference::Kind values. The problem was that we wanted to reuse existing relocation type values as Reference::Kind values. But then how can the YAML write know how to convert a value to a string? The fix is to change the 32-bit Reference::Kind into a tuple with an 8-bit namespace (e.g. ELF, COFFF, etc), an 8-bit architecture (e.g. x86_64, PowerPC, etc), and a 16-bit value. This tuple system allows conversion to and from strings with no ambiguities. llvm-svn: 197727
2013-12-20 05:58:00 +08:00
ELF-i386: - kind: R_386_PC32
add support for merging common strings llvm-svn: 174990
2013-02-13 02:46:53 +08:00
ELF-i386: offset: 17
ELF-i386: target: puts
ELF-i386: addend: 252
Fix trailing whitespace. llvm-svn: 200182
2014-01-27 11:09:26 +08:00
ELF-i386: undefined-atoms:
add support for merging common strings llvm-svn: 174990
2013-02-13 02:46:53 +08:00
ELF-i386: - name: puts
Fix trailing whitespace. llvm-svn: 200182
2014-01-27 11:09:26 +08:00
ELF-i386: absolute-atoms:
add support for merging common strings llvm-svn: 174990
2013-02-13 02:46:53 +08:00
ELF-i386: - name: test.c
ELF-i386: scope: static
ELF-i386: value: 0x0000000000000000