summaryrefslogtreecommitdiff
path: root/lld/test/ELF/startstop-shared.s
AgeCommit message (Collapse)Author
2019-05-01[test] Change llvm-readobj -long-option to --long-option or well-known short ↵Fangrui Song
options. NFC Also change some options that have different semantics (cause confusion) in llvm-readelf mode: -s => -S -t => --symbols -sd => --section-data llvm-svn: 359651
2018-03-20[ELF] - Make __start_/__stop_<section_name> symbols STV_PROTECTEDGeorge Rimar
There are no reasons for them to be STV_DEFAULT, recently bfd did the same change. Differential revision: https://reviews.llvm.org/D44566 llvm-svn: 327983
2016-08-19[ELF] - Give automatically generated __start_* and __stop_* symbols default ↵George Rimar
visibility. This patch is opposite to D19024, which made this symbols to be hidden by default. Unfortunately FreeBSD loader wants to see start_set_modmetadata_set/stop_set_modmetadata_set in the dynamic symbol table. They were not placed there because had hidden visibility. Patch makes them to have default visibility again. Differential revision: https://reviews.llvm.org/D23552 llvm-svn: 279262
2016-05-04Don't depend on dynamic relocatinos in ro sections.Rafael Espindola
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-04-12ELF: Give automatically generated __start_* and __stop_* symbols hidden ↵Peter Collingbourne
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-05Delete broken code.Rafael Espindola
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
2015-11-18Rename ld.lld2 to ld.lld since it is the default.Rafael Espindola
llvm-svn: 253437
2015-11-17Rename test/elf2 to test/ELF.Rafael Espindola
llvm-svn: 253313