maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/MC/ELF/relocation.s

100 lines
3.9 KiB
ArmAsm
Raw Normal View History

Fix the interpretation of a 0 st_name. The ELF spec is very clear: ----------------------------------------------------------------------------- If the value is non-zero, it represents a string table index that gives the symbol name. Otherwise, the symbol table entry has no name. -------------------------------------------------------------------------- In particular, a st_name of 0 most certainly doesn't mean that the symbol has the same name as the section. llvm-svn: 238899
2015-06-03 13:14:22 +08:00
// RUN: llvm-mc -filetype=obj -triple x86_64-pc-linux-gnu %s -o - | llvm-readobj -s -sr | FileCheck %s
Produce a R_X86_64_32 when the value is >=0. llvm-svn: 114339
2010-09-21 03:20:47 +08:00
Implement R_X86_64_GOTTPOFF, R_X86_64_TLSGD and R_X86_64_TPOFF32. llvm-svn: 117481
2010-10-28 04:28:07 +08:00
// Test that we produce the correct relocation.
Produce a R_X86_64_32 when the value is >=0. llvm-svn: 114339
2010-09-21 03:20:47 +08:00
Compute A-B if both A and B are in the same comdat section. Part of pr23272. A small annoyance with the assembly syntax we implement is that given an expression there is no way to know if what is desired is the value of that expression for the symbols in this file or for the final values of those symbols in a link. The first case is useful for use in sections that get discarded or ignored if the section they are describing is discarded. For axample, consider A-B where A and B are in the same comdat section. We can compute the value of the difference in the section that is present in the current .o and if that section survives to the final DSO the value will still will be correct. But the section is in a comdat. Another section from another object file might be used istead. We know that that section will define A and B, but we have no idea what the value of A-B might be. In practice we have to assume that the intention is to compute the value in the current section since otherwise the is no way to create something like the debug aranges section. llvm-svn: 235222
2015-04-18 04:05:17 +08:00
.section .pr23272,"aGw",@progbits,pr23272,comdat
.globl pr23272
pr23272:
pr23272_2:
Look past locals in comdats. We have to avoid converting a reference to a global into a reference to a local, but it is fine to look past a local. Patch by Vasileios Kalintiris. I just moved the comment and added thet test. llvm-svn: 235300
2015-04-20 20:44:06 +08:00
pr23272_3 = pr23272_2
Compute A-B if both A and B are in the same comdat section. Part of pr23272. A small annoyance with the assembly syntax we implement is that given an expression there is no way to know if what is desired is the value of that expression for the symbols in this file or for the final values of those symbols in a link. The first case is useful for use in sections that get discarded or ignored if the section they are describing is discarded. For axample, consider A-B where A and B are in the same comdat section. We can compute the value of the difference in the section that is present in the current .o and if that section survives to the final DSO the value will still will be correct. But the section is in a comdat. Another section from another object file might be used istead. We know that that section will define A and B, but we have no idea what the value of A-B might be. In practice we have to assume that the intention is to compute the value in the current section since otherwise the is no way to create something like the debug aranges section. llvm-svn: 235222
2015-04-18 04:05:17 +08:00
.text
Correctly produce R_X86_64_32 or R_X86_64_32S. With this patch in movq $foo, foo(%rip) foo: .long foo We produce a R_X86_64_32S for the first relocation and R_X86_64_32 for the second one. llvm-svn: 115134
2010-09-30 11:11:42 +08:00
bar:
Implement R_X86_64_GOTTPOFF, R_X86_64_TLSGD and R_X86_64_TPOFF32. llvm-svn: 117481
2010-10-28 04:28:07 +08:00
movl $bar, %edx # R_X86_64_32
movq $bar, %rdx # R_X86_64_32S
movq $bar, bar(%rip) # R_X86_64_32S
movl bar, %edx # R_X86_64_32S
movq bar, %rdx # R_X86_64_32S
.long bar # R_X86_64_32
leaq foo@GOTTPOFF(%rip), %rax # R_X86_64_GOTTPOFF
leaq foo@TLSGD(%rip), %rax # R_X86_64_TLSGD
leaq foo@TPOFF(%rax), %rax # R_X86_64_TPOFF32
Implement TLSLD. llvm-svn: 117547
2010-10-28 23:02:40 +08:00
leaq foo@TLSLD(%rip), %rdi # R_X86_64_TLSLD
Add support for lowercase variants. llvm-svn: 124071
2011-01-24 00:11:25 +08:00
leaq foo@dtpoff(%rax), %rcx # R_X86_64_DTPOFF32
This commit adds some (but not all) of the x86-64 relocations that are not currently supported in the ELF object writer, along with a simple test case. llvm-svn: 193709
2013-10-31 02:47:25 +08:00
movabs foo@GOT, %rax # R_X86_64_GOT64
movabs foo@GOTOFF, %rax # R_X86_64_GOTOFF64
Make pushq produce signed relocations. llvm-svn: 122005
2010-12-17 06:50:01 +08:00
pushq $bar
Handle reloc_riprel_4byte_movq_load. Should make the bots happy. llvm-svn: 122579
2010-12-27 10:03:24 +08:00
movq foo(%rip), %rdx
Fix PR8878. llvm-svn: 122658
2011-01-02 03:05:35 +08:00
leaq foo-bar(%r14),%r14
ADD64ri32 sign extends its argument, so we need to use a R_X86_64_32S. Fixes PR9934. We really need to start tblgening the relocation info :-( llvm-svn: 131669
2011-05-20 04:32:34 +08:00
addq $bar,%rax # R_X86_64_32S
Integrate Assembler: Support X86_64_DTPOFF64 relocations llvm-svn: 185131
2013-06-28 12:24:32 +08:00
.quad foo@DTPOFF
X86: Use R_X86_64_TPOFF64 for FK_Data_8 Summary: LLVM would crash when trying to come up with a relocation type for assembly like: movabsq $V@TPOFF, %rax Instead, we say the relocation type is R_X86_64_TPOFF64. Fixes PR17274. Reviewers: dblaikie, nrieck, rafael CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1717 llvm-svn: 191163
2013-09-22 13:30:16 +08:00
movabsq $baz@TPOFF, %rax
[x86] Support R_386_PC8, R_386_PC16 and R_X86_64_PC8 llvm-svn: 198763
2014-01-08 20:58:40 +08:00
.word foo-bar
.byte foo-bar
Produce a R_X86_64_32 when the value is >=0. llvm-svn: 114339
2010-09-21 03:20:47 +08:00
Fix pr19645. The fix itself is fairly simple: move getAccessVariant to MCValue so that we replace the old weak expression evaluation with the far more general EvaluateAsRelocatable. This then requires that EvaluateAsRelocatable stop when it finds a non trivial reference kind. And that in turn requires the ELF writer to look harder for weak references. Last but not least, this found a case where we were being bug by bug compatible with gas and accepting an invalid input. I reported pr19647 to track it. llvm-svn: 207920
2014-05-04 03:57:04 +08:00
# this should probably be an error...
Look through variables when computing relocations. Given bar = foo + 4 .long bar MC would eat the 4. GNU as includes it in the relocation. The rule seems to be that a variable that defines a symbol is used in the relocation and one that does not define a symbol is evaluated and the result included in the relocation. Fixing this unfortunately required some other changes: * Since the variable is now evaluated, it would prevent the ELF writer from noticing the weakref marker the elf streamer uses. This patch then replaces that with a VariantKind in MCSymbolRefExpr. * Using VariantKind then requires us to look past other VariantKind to see .weakref bar,foo call bar@PLT doing this also fixes zed = foo +2 call zed@PLT so that is a good thing. * Looking past VariantKind means that the relocation selection has to use the fixup instead of the target. This is a reboot of the previous fixes for MC. I will watch the sanitizer buildbot and wait for a build before adding back the previous fixes. llvm-svn: 204294
2014-03-20 10:12:01 +08:00
zed = foo +2
call zed@PLT
Fix up MCFixup::getAccessVariant to handle unary expressions. This allows correct relocations to be generated for a symbolic address that is being adjusted by a negative constant. Since r204294, such expressions have triggered undefined behavior when LLVM was built without assertions. Credit goes to Rafael for this patch; I'm submitting it on his behalf as he is on vacation this week. llvm-svn: 206192
2014-04-15 00:50:22 +08:00
leaq -1+foo(%rip), %r11
Handle _GLOBAL_OFFSET_TABLE_ in 64 bit mode. With this MC is able to handle _GLOBAL_OFFSET_TABLE_ in 64 bit mode, which is needed for medium and large code models. This fixes pr19470. llvm-svn: 206793
2014-04-22 05:15:45 +08:00
movl $_GLOBAL_OFFSET_TABLE_, %eax
movabs $_GLOBAL_OFFSET_TABLE_, %rax
[MC][Target] Implement support for R_X86_64_SIZE{32,64}. Differential Revision: D7990 Reviewed by: rafael, majnemer llvm-svn: 231216
2015-03-04 14:49:39 +08:00
.quad blah@SIZE # R_X86_64_SIZE64
.quad blah@SIZE + 32 # R_X86_64_SIZE64
.quad blah@SIZE - 32 # R_X86_64_SIZE64
movl blah@SIZE, %eax # R_X86_64_SIZE32
movl blah@SIZE + 32, %eax # R_X86_64_SIZE32
movl blah@SIZE - 32, %eax # R_X86_64_SIZE32
Reorganize the x86 ELF relocation selection logic. The main differences are: * Split in 32 and 64 bit functions. * First switch on the Modifier so that we have only one non fully covered switch. * Map the fixup kind first to a x86_64 (or i386) specific enum, to make it easy to handle cases like X86::reloc_riprel_4byte_movq_load. * Switch on IsPCRel last, which reduces code duplication. Fixes pr22308. llvm-svn: 232837
2015-03-21 03:48:54 +08:00
.long foo@gotpcrel
.long foo@plt
Compute A-B if both A and B are in the same comdat section. Part of pr23272. A small annoyance with the assembly syntax we implement is that given an expression there is no way to know if what is desired is the value of that expression for the symbols in this file or for the final values of those symbols in a link. The first case is useful for use in sections that get discarded or ignored if the section they are describing is discarded. For axample, consider A-B where A and B are in the same comdat section. We can compute the value of the difference in the section that is present in the current .o and if that section survives to the final DSO the value will still will be correct. But the section is in a comdat. Another section from another object file might be used istead. We know that that section will define A and B, but we have no idea what the value of A-B might be. In practice we have to assume that the intention is to compute the value in the current section since otherwise the is no way to create something like the debug aranges section. llvm-svn: 235222
2015-04-18 04:05:17 +08:00
.quad pr23272_2 - pr23272
Look past locals in comdats. We have to avoid converting a reference to a global into a reference to a local, but it is fine to look past a local. Patch by Vasileios Kalintiris. I just moved the comment and added thet test. llvm-svn: 235300
2015-04-20 20:44:06 +08:00
.quad pr23272_3 - pr23272
Handle 16 bit PC relative relocations. Fixes pr23771. llvm-svn: 239214
2015-06-06 10:29:56 +08:00
.code16
call pr23771
Replace coff-/elf-dump with llvm-readobj llvm-svn: 179361
2013-04-12 12:06:46 +08:00
// CHECK: Section {
Change how we iterate over relocations on ELF. For COFF and MachO, sections semantically have relocations that apply to them. That is not the case on ELF. In relocatable objects (.o), a section with relocations in ELF has offsets to another section where the relocations should be applied. In dynamic objects and executables, relocations don't have an offset, they have a virtual address. The section sh_info may or may not point to another section, but that is not actually used for resolving the relocations. This patch exposes that in the ObjectFile API. It has the following advantages: * Most (all?) clients can handle this more efficiently. They will normally walk all relocations, so doing an effort to iterate in a particular order doesn't save time. * llvm-readobj now prints relocations in the same way the native readelf does. * probably most important, relocations that don't point to any section are now visible. This is the case of relocations in the rela.dyn section. See the updated relocation-executable.test for example. llvm-svn: 182908
2013-05-30 11:05:14 +08:00
// CHECK: Name: .rela.text
Replace coff-/elf-dump with llvm-readobj llvm-svn: 179361
2013-04-12 12:06:46 +08:00
// CHECK: Relocations [
// CHECK-NEXT: 0x1 R_X86_64_32 .text
// CHECK-NEXT: 0x8 R_X86_64_32S .text
// CHECK-NEXT: 0x13 R_X86_64_32S .text
// CHECK-NEXT: 0x1A R_X86_64_32S .text
// CHECK-NEXT: 0x22 R_X86_64_32S .text
// CHECK-NEXT: 0x26 R_X86_64_32 .text
// CHECK-NEXT: 0x2D R_X86_64_GOTTPOFF foo 0xFFFFFFFFFFFFFFFC
// CHECK-NEXT: 0x34 R_X86_64_TLSGD foo 0xFFFFFFFFFFFFFFFC
// CHECK-NEXT: 0x3B R_X86_64_TPOFF32 foo 0x0
// CHECK-NEXT: 0x42 R_X86_64_TLSLD foo 0xFFFFFFFFFFFFFFFC
// CHECK-NEXT: 0x49 R_X86_64_DTPOFF32 foo 0x0
This commit adds some (but not all) of the x86-64 relocations that are not currently supported in the ELF object writer, along with a simple test case. llvm-svn: 193709
2013-10-31 02:47:25 +08:00
// CHECK-NEXT: 0x4F R_X86_64_GOT64 foo 0x0
// CHECK-NEXT: 0x59 R_X86_64_GOTOFF64 foo 0x0
// CHECK-NEXT: 0x62 R_X86_64_32S .text 0x0
// CHECK-NEXT: 0x69 R_X86_64_PC32 foo 0xFFFFFFFFFFFFFFFC
// CHECK-NEXT: 0x70 R_X86_64_PC32 foo 0x70
// CHECK-NEXT: 0x77 R_X86_64_32S .text 0x0
// CHECK-NEXT: 0x7B R_X86_64_DTPOFF64 foo 0x0
// CHECK-NEXT: 0x85 R_X86_64_TPOFF64 baz 0x0
[x86] Support R_386_PC8, R_386_PC16 and R_X86_64_PC8 llvm-svn: 198763
2014-01-08 20:58:40 +08:00
// CHECK-NEXT: 0x8D R_X86_64_PC16 foo 0x8D
// CHECK-NEXT: 0x8F R_X86_64_PC8 foo 0x8F
Fix pr19645. The fix itself is fairly simple: move getAccessVariant to MCValue so that we replace the old weak expression evaluation with the far more general EvaluateAsRelocatable. This then requires that EvaluateAsRelocatable stop when it finds a non trivial reference kind. And that in turn requires the ELF writer to look harder for weak references. Last but not least, this found a case where we were being bug by bug compatible with gas and accepting an invalid input. I reported pr19647 to track it. llvm-svn: 207920
2014-05-04 03:57:04 +08:00
// CHECK-NEXT: 0x91 R_X86_64_PLT32 zed 0xFFFFFFFFFFFFFFFC
Fix up MCFixup::getAccessVariant to handle unary expressions. This allows correct relocations to be generated for a symbolic address that is being adjusted by a negative constant. Since r204294, such expressions have triggered undefined behavior when LLVM was built without assertions. Credit goes to Rafael for this patch; I'm submitting it on his behalf as he is on vacation this week. llvm-svn: 206192
2014-04-15 00:50:22 +08:00
// CHECK-NEXT: 0x98 R_X86_64_PC32 foo 0xFFFFFFFFFFFFFFFB
Handle _GLOBAL_OFFSET_TABLE_ in 64 bit mode. With this MC is able to handle _GLOBAL_OFFSET_TABLE_ in 64 bit mode, which is needed for medium and large code models. This fixes pr19470. llvm-svn: 206793
2014-04-22 05:15:45 +08:00
// CHECK-NEXT: 0x9D R_X86_64_GOTPC32 _GLOBAL_OFFSET_TABLE_ 0x1
// CHECK-NEXT: 0xA3 R_X86_64_GOTPC64 _GLOBAL_OFFSET_TABLE_ 0x2
[MC][Target] Implement support for R_X86_64_SIZE{32,64}. Differential Revision: D7990 Reviewed by: rafael, majnemer llvm-svn: 231216
2015-03-04 14:49:39 +08:00
// CHECK-NEXT: 0xAB R_X86_64_SIZE64 blah 0x0
// CHECK-NEXT: 0xB3 R_X86_64_SIZE64 blah 0x20
// CHECK-NEXT: 0xBB R_X86_64_SIZE64 blah 0xFFFFFFFFFFFFFFE0
// CHECK-NEXT: 0xC6 R_X86_64_SIZE32 blah 0x0
// CHECK-NEXT: 0xCD R_X86_64_SIZE32 blah 0x20
// CHECK-NEXT: 0xD4 R_X86_64_SIZE32 blah 0xFFFFFFFFFFFFFFE0
Reorganize the x86 ELF relocation selection logic. The main differences are: * Split in 32 and 64 bit functions. * First switch on the Modifier so that we have only one non fully covered switch. * Map the fixup kind first to a x86_64 (or i386) specific enum, to make it easy to handle cases like X86::reloc_riprel_4byte_movq_load. * Switch on IsPCRel last, which reduces code duplication. Fixes pr22308. llvm-svn: 232837
2015-03-21 03:48:54 +08:00
// CHECK-NEXT: 0xD8 R_X86_64_GOTPCREL foo 0x0
// CHECK-NEXT: 0xDC R_X86_64_PLT32 foo 0x0
Handle 16 bit PC relative relocations. Fixes pr23771. llvm-svn: 239214
2015-06-06 10:29:56 +08:00
// CHECK-NEXT: 0xF1 R_X86_64_PC16 pr23771 0xFFFFFFFFFFFFFFFE
Replace coff-/elf-dump with llvm-readobj llvm-svn: 179361
2013-04-12 12:06:46 +08:00
// CHECK-NEXT: ]
// CHECK-NEXT: }