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/common.s

60 lines
1.4 KiB
ArmAsm
Raw Normal View History

Keep the largest common symbol. This requires templating some functions over ELFT, but that opens other cleanup opportunities for future patches. llvm-svn: 246405
2015-08-31 09:16:19 +08:00
// RUN: llvm-mc -filetype=obj -triple=x86_64-pc-linux %s -o %t
// RUN: llvm-mc -filetype=obj -triple=x86_64-pc-linux %p/Inputs/common.s -o %t2
Rename ld.lld2 to ld.lld since it is the default. llvm-svn: 253437
2015-11-18 14:11:01 +08:00
// RUN: ld.lld %t %t2 -o %t3
Set the correct value for the common symbols. In the relocatable object it is the alignment, but in the linked file it is a regular address. llvm-svn: 246505
2015-09-01 06:55:21 +08:00
// RUN: llvm-readobj -t -s %t3 | FileCheck %s
Keep the largest common symbol. This requires templating some functions over ELFT, but that opens other cleanup opportunities for future patches. llvm-svn: 246405
2015-08-31 09:16:19 +08:00
// REQUIRES: x86
Set the correct value for the common symbols. In the relocatable object it is the alignment, but in the linked file it is a regular address. llvm-svn: 246505
2015-09-01 06:55:21 +08:00
// CHECK: Name: .bss
// CHECK-NEXT: Type: SHT_NOBITS
// CHECK-NEXT: Flags [
// CHECK-NEXT: SHF_ALLOC
// CHECK-NEXT: SHF_WRITE
// CHECK-NEXT: ]
lld: Default image base address to 0x200000 on x86-64 Align to the large page size (known as a superpage or huge page). FreeBSD automatically promotes large, superpage-aligned allocations. Differential Revision: https://reviews.llvm.org/D27042 llvm-svn: 287782
2016-11-24 01:44:02 +08:00
// CHECK-NEXT: Address: 0x201000
Sort common symbols by alignment. llvm-svn: 246511
2015-09-01 08:16:38 +08:00
// CHECK-NEXT: Offset:
Currently lld creates a single section to collect all commons. There is no way to separate commons based on file name patterns. The following linker script construct does not work because commons are allocated before section placement is done and the only synthesized BssSection that holds all commons has no file associated with it: SECTIONS { .common_0 : { *file0.o(COMMON) }} This patch changes the allocation of commons to create a section per common symbol and let the section logic do the layout. Differential revision: https://reviews.llvm.org/D37489 llvm-svn: 312796
2017-09-09 00:22:43 +08:00
// CHECK-NEXT: Size: 36
Adjust the .bss alignment to include common symbols. llvm-svn: 262840
2016-03-08 01:43:39 +08:00
// CHECK-NEXT: Link: 0
// CHECK-NEXT: Info: 0
// CHECK-NEXT: AddressAlignment: 16
Set the correct value for the common symbols. In the relocatable object it is the alignment, but in the linked file it is a regular address. llvm-svn: 246505
2015-09-01 06:55:21 +08:00
Use a MapVector to output symbols in a deterministic order. We used to sort the symbols at the very end, but we need to know the order earlier so that we can create reference to them in the dynamic relocations. Thanks to Igor Kudrin for pointing out the problem. llvm-svn: 247911
2015-09-18 02:26:25 +08:00
// CHECK: Name: sym1
Currently lld creates a single section to collect all commons. There is no way to separate commons based on file name patterns. The following linker script construct does not work because commons are allocated before section placement is done and the only synthesized BssSection that holds all commons has no file associated with it: SECTIONS { .common_0 : { *file0.o(COMMON) }} This patch changes the allocation of commons to create a section per common symbol and let the section logic do the layout. Differential revision: https://reviews.llvm.org/D37489 llvm-svn: 312796
2017-09-09 00:22:43 +08:00
// CHECK-NEXT: Value: 0x201000
Use a MapVector to output symbols in a deterministic order. We used to sort the symbols at the very end, but we need to know the order earlier so that we can create reference to them in the dynamic relocations. Thanks to Igor Kudrin for pointing out the problem. llvm-svn: 247911
2015-09-18 02:26:25 +08:00
// CHECK-NEXT: Size: 8
Remember the maximum alignment used to refer to a common symbol. llvm-svn: 246517
2015-09-01 09:19:12 +08:00
// CHECK-NEXT: Binding: Global
// CHECK-NEXT: Type: Object
// CHECK-NEXT: Other: 0
// CHECK-NEXT: Section: .bss
Use a MapVector to output symbols in a deterministic order. We used to sort the symbols at the very end, but we need to know the order earlier so that we can create reference to them in the dynamic relocations. Thanks to Igor Kudrin for pointing out the problem. llvm-svn: 247911
2015-09-18 02:26:25 +08:00
// CHECK: Name: sym2
Currently lld creates a single section to collect all commons. There is no way to separate commons based on file name patterns. The following linker script construct does not work because commons are allocated before section placement is done and the only synthesized BssSection that holds all commons has no file associated with it: SECTIONS { .common_0 : { *file0.o(COMMON) }} This patch changes the allocation of commons to create a section per common symbol and let the section logic do the layout. Differential revision: https://reviews.llvm.org/D37489 llvm-svn: 312796
2017-09-09 00:22:43 +08:00
// CHECK-NEXT: Value: 0x201008
Use a MapVector to output symbols in a deterministic order. We used to sort the symbols at the very end, but we need to know the order earlier so that we can create reference to them in the dynamic relocations. Thanks to Igor Kudrin for pointing out the problem. llvm-svn: 247911
2015-09-18 02:26:25 +08:00
// CHECK-NEXT: Size: 8
Sort common symbols by alignment. llvm-svn: 246511
2015-09-01 08:16:38 +08:00
// CHECK-NEXT: Binding: Global
// CHECK-NEXT: Type: Object
// CHECK-NEXT: Other: 0
// CHECK-NEXT: Section: .bss
Use a MapVector to output symbols in a deterministic order. We used to sort the symbols at the very end, but we need to know the order earlier so that we can create reference to them in the dynamic relocations. Thanks to Igor Kudrin for pointing out the problem. llvm-svn: 247911
2015-09-18 02:26:25 +08:00
// CHECK: Name: sym3
Currently lld creates a single section to collect all commons. There is no way to separate commons based on file name patterns. The following linker script construct does not work because commons are allocated before section placement is done and the only synthesized BssSection that holds all commons has no file associated with it: SECTIONS { .common_0 : { *file0.o(COMMON) }} This patch changes the allocation of commons to create a section per common symbol and let the section logic do the layout. Differential revision: https://reviews.llvm.org/D37489 llvm-svn: 312796
2017-09-09 00:22:43 +08:00
// CHECK-NEXT: Value: 0x201010
Use a MapVector to output symbols in a deterministic order. We used to sort the symbols at the very end, but we need to know the order earlier so that we can create reference to them in the dynamic relocations. Thanks to Igor Kudrin for pointing out the problem. llvm-svn: 247911
2015-09-18 02:26:25 +08:00
// CHECK-NEXT: Size: 2
Keep the largest common symbol. This requires templating some functions over ELFT, but that opens other cleanup opportunities for future patches. llvm-svn: 246405
2015-08-31 09:16:19 +08:00
// CHECK-NEXT: Binding: Global
// CHECK-NEXT: Type: Object
// CHECK-NEXT: Other: 0
Assign common symbols to the .bss output section. llvm-svn: 246503
2015-09-01 06:33:21 +08:00
// CHECK-NEXT: Section: .bss
Keep the largest common symbol. This requires templating some functions over ELFT, but that opens other cleanup opportunities for future patches. llvm-svn: 246405
2015-08-31 09:16:19 +08:00
Use a MapVector to output symbols in a deterministic order. We used to sort the symbols at the very end, but we need to know the order earlier so that we can create reference to them in the dynamic relocations. Thanks to Igor Kudrin for pointing out the problem. llvm-svn: 247911
2015-09-18 02:26:25 +08:00
// CHECK: Name: sym4
Currently lld creates a single section to collect all commons. There is no way to separate commons based on file name patterns. The following linker script construct does not work because commons are allocated before section placement is done and the only synthesized BssSection that holds all commons has no file associated with it: SECTIONS { .common_0 : { *file0.o(COMMON) }} This patch changes the allocation of commons to create a section per common symbol and let the section logic do the layout. Differential revision: https://reviews.llvm.org/D37489 llvm-svn: 312796
2017-09-09 00:22:43 +08:00
// CHECK-NEXT: Value: 0x201020
Use a MapVector to output symbols in a deterministic order. We used to sort the symbols at the very end, but we need to know the order earlier so that we can create reference to them in the dynamic relocations. Thanks to Igor Kudrin for pointing out the problem. llvm-svn: 247911
2015-09-18 02:26:25 +08:00
// CHECK-NEXT: Size: 4
Keep the largest common symbol. This requires templating some functions over ELFT, but that opens other cleanup opportunities for future patches. llvm-svn: 246405
2015-08-31 09:16:19 +08:00
// CHECK-NEXT: Binding: Global
// CHECK-NEXT: Type: Object
// CHECK-NEXT: Other: 0
Assign common symbols to the .bss output section. llvm-svn: 246503
2015-09-01 06:33:21 +08:00
// CHECK-NEXT: Section: .bss
Keep the largest common symbol. This requires templating some functions over ELFT, but that opens other cleanup opportunities for future patches. llvm-svn: 246405
2015-08-31 09:16:19 +08:00
.globl _start
_start:
.comm sym1,4,4
.comm sym2,8,4
Sort common symbols by alignment. llvm-svn: 246511
2015-09-01 08:16:38 +08:00
.comm sym3,2,2
Remember the maximum alignment used to refer to a common symbol. llvm-svn: 246517
2015-09-01 09:19:12 +08:00
.comm sym4,4,2