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/startstop-shared.s

27 lines
738 B
ArmAsm
Raw Normal View History

Add an interesting case where we were already producing the correct result. llvm-svn: 250544
2015-10-17 03:57:42 +08:00
// REQUIRES: x86
// RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %s -o %t.o
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.o -o %t.so -shared
Add an interesting case where we were already producing the correct result. llvm-svn: 250544
2015-10-17 03:57:42 +08:00
// RUN: llvm-readobj -r -t %t.so | FileCheck %s
Don't depend on dynamic relocatinos in ro sections. Currently we don't check when creating relative relocations if the section is read only or not. I am about to fix that, so first update the patches that depend on the current behavior. llvm-svn: 268542
2016-05-05 04:25:19 +08:00
.data
Add an interesting case where we were already producing the correct result. llvm-svn: 250544
2015-10-17 03:57:42 +08:00
.quad __start_foo
Don't depend on dynamic relocatinos in ro sections. Currently we don't check when creating relative relocations if the section is read only or not. I am about to fix that, so first update the patches that depend on the current behavior. llvm-svn: 268542
2016-05-05 04:25:19 +08:00
.section foo,"aw"
ELF: Give automatically generated __start_* and __stop_* symbols hidden visibility. These symbols describe a property of a linkage unit, so it seems reasonable to limit their visibility to the linkage unit. Furthermore the use cases I am aware of do not require more than hidden visibility. This is a departure from the behavior of the bfd and gold linkers. However, it is unclear that the decision to give these symbols default visibility in those linkers was made deliberately. The __start_*/__stop_* feature was added to the bfd linker in 1994 [1], while the visibility feature was added about five years later [2], so it may have been that the visibility of these symbols was not considered. The feature was implemented in gold [3] in the same way; the behavior may have simply been copied from bfd. The only related discussion I could find on the binutils mailing list [4] was a user issue which would most likely not have occurred if the symbols had hidden visibility. [1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=5efddb2e7c3229b569a862205f61d42860af678b [2] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=0fc731e447cd01e7fc35197b487ff0e4fd25afca [3] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=bfd58944a64b0997a310b95fbe0423338961e71c [4] https://sourceware.org/ml/binutils/2014-05/msg00011.html Differential Revision: http://reviews.llvm.org/D19024 llvm-svn: 266121
2016-04-13 04:41:42 +08:00
// By default the symbol is hidden.
// CHECK: R_X86_64_RELATIVE - 0x[[ADDR1:.*]]
Add an interesting case where we were already producing the correct result. llvm-svn: 250544
2015-10-17 03:57:42 +08:00
.hidden __start_bar
.quad __start_bar
.section bar,"a"
ELF: Give automatically generated __start_* and __stop_* symbols hidden visibility. These symbols describe a property of a linkage unit, so it seems reasonable to limit their visibility to the linkage unit. Furthermore the use cases I am aware of do not require more than hidden visibility. This is a departure from the behavior of the bfd and gold linkers. However, it is unclear that the decision to give these symbols default visibility in those linkers was made deliberately. The __start_*/__stop_* feature was added to the bfd linker in 1994 [1], while the visibility feature was added about five years later [2], so it may have been that the visibility of these symbols was not considered. The feature was implemented in gold [3] in the same way; the behavior may have simply been copied from bfd. The only related discussion I could find on the binutils mailing list [4] was a user issue which would most likely not have occurred if the symbols had hidden visibility. [1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=5efddb2e7c3229b569a862205f61d42860af678b [2] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=0fc731e447cd01e7fc35197b487ff0e4fd25afca [3] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=bfd58944a64b0997a310b95fbe0423338961e71c [4] https://sourceware.org/ml/binutils/2014-05/msg00011.html Differential Revision: http://reviews.llvm.org/D19024 llvm-svn: 266121
2016-04-13 04:41:42 +08:00
// References do not affect the visibility.
// CHECK: R_X86_64_RELATIVE - 0x[[ADDR2:.*]]
Add an interesting case where we were already producing the correct result. llvm-svn: 250544
2015-10-17 03:57:42 +08:00
// CHECK: Name: __start_bar
ELF: Give automatically generated __start_* and __stop_* symbols hidden visibility. These symbols describe a property of a linkage unit, so it seems reasonable to limit their visibility to the linkage unit. Furthermore the use cases I am aware of do not require more than hidden visibility. This is a departure from the behavior of the bfd and gold linkers. However, it is unclear that the decision to give these symbols default visibility in those linkers was made deliberately. The __start_*/__stop_* feature was added to the bfd linker in 1994 [1], while the visibility feature was added about five years later [2], so it may have been that the visibility of these symbols was not considered. The feature was implemented in gold [3] in the same way; the behavior may have simply been copied from bfd. The only related discussion I could find on the binutils mailing list [4] was a user issue which would most likely not have occurred if the symbols had hidden visibility. [1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=5efddb2e7c3229b569a862205f61d42860af678b [2] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=0fc731e447cd01e7fc35197b487ff0e4fd25afca [3] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=bfd58944a64b0997a310b95fbe0423338961e71c [4] https://sourceware.org/ml/binutils/2014-05/msg00011.html Differential Revision: http://reviews.llvm.org/D19024 llvm-svn: 266121
2016-04-13 04:41:42 +08:00
// CHECK-NEXT: Value: 0x[[ADDR2]]
Delete broken code. A synthetic symbol can be global or local, and with the current infrastructure we don't need any special code for it. Fixes PR27228. llvm-svn: 265478
2016-04-06 06:08:39 +08:00
// CHECK-NEXT: Size:
// CHECK-NEXT: Binding: Local
// CHECK: Name: __start_foo
ELF: Give automatically generated __start_* and __stop_* symbols hidden visibility. These symbols describe a property of a linkage unit, so it seems reasonable to limit their visibility to the linkage unit. Furthermore the use cases I am aware of do not require more than hidden visibility. This is a departure from the behavior of the bfd and gold linkers. However, it is unclear that the decision to give these symbols default visibility in those linkers was made deliberately. The __start_*/__stop_* feature was added to the bfd linker in 1994 [1], while the visibility feature was added about five years later [2], so it may have been that the visibility of these symbols was not considered. The feature was implemented in gold [3] in the same way; the behavior may have simply been copied from bfd. The only related discussion I could find on the binutils mailing list [4] was a user issue which would most likely not have occurred if the symbols had hidden visibility. [1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=5efddb2e7c3229b569a862205f61d42860af678b [2] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=0fc731e447cd01e7fc35197b487ff0e4fd25afca [3] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=bfd58944a64b0997a310b95fbe0423338961e71c [4] https://sourceware.org/ml/binutils/2014-05/msg00011.html Differential Revision: http://reviews.llvm.org/D19024 llvm-svn: 266121
2016-04-13 04:41:42 +08:00
// CHECK-NEXT: Value: 0x[[ADDR1]]
Delete broken code. A synthetic symbol can be global or local, and with the current infrastructure we don't need any special code for it. Fixes PR27228. llvm-svn: 265478
2016-04-06 06:08:39 +08:00
// CHECK-NEXT: Size:
ELF: Give automatically generated __start_* and __stop_* symbols hidden visibility. These symbols describe a property of a linkage unit, so it seems reasonable to limit their visibility to the linkage unit. Furthermore the use cases I am aware of do not require more than hidden visibility. This is a departure from the behavior of the bfd and gold linkers. However, it is unclear that the decision to give these symbols default visibility in those linkers was made deliberately. The __start_*/__stop_* feature was added to the bfd linker in 1994 [1], while the visibility feature was added about five years later [2], so it may have been that the visibility of these symbols was not considered. The feature was implemented in gold [3] in the same way; the behavior may have simply been copied from bfd. The only related discussion I could find on the binutils mailing list [4] was a user issue which would most likely not have occurred if the symbols had hidden visibility. [1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=5efddb2e7c3229b569a862205f61d42860af678b [2] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=0fc731e447cd01e7fc35197b487ff0e4fd25afca [3] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=bfd58944a64b0997a310b95fbe0423338961e71c [4] https://sourceware.org/ml/binutils/2014-05/msg00011.html Differential Revision: http://reviews.llvm.org/D19024 llvm-svn: 266121
2016-04-13 04:41:42 +08:00
// CHECK-NEXT: Binding: Local