SHF_LINK_ORDER's original semantics make upgrade difficult
Fangrui Song
maskray@google.com
Thu Aug 6 05:33:09 GMT 2020
More information about the Binutils mailing list
Thu Aug 6 05:33:09 GMT 2020
- Previous message (by thread): [PATCH] bpf: relocation fixes for eBPF ELF backend
- Next message (by thread): ld: Why does ppc64 have --no-toc-optimize instead of reusing --no-relax?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
A short update about what some LLVM folks have done on SHF_LINK_ORDER: * New syntax was added to support SHF_LINK_ORDER with sh_link=0 (literal 0 in the symbol position) (https://reviews.llvm.org/D72899 ) .section linkorder,"ao",@progbits,0 GNU as feature request: https://sourceware.org/bugzilla/show_bug.cgi?id=26253 Relocatable links and LTO dead stripping are two things which can lead to sh_link=0 * LLD allows mixed sh_link!=0 and sh_link=0 components now. (https://reviews.llvm.org/D72904 ) GNU ld feature request: https://sourceware.org/bugzilla/show_bug.cgi?id=26256 * To allow "upgrade" (add the SHF_LINK_ORDER flag to an existing non-SHF_LINK_ORDER section, and allow linking of mixed old and new objects): Mixed non-SHF_LINK_ORDER and SHF_LINK_ORDER components should be allowed. Pending (promising): https://reviews.llvm.org/D84001 GNU ld feature request: https://sourceware.org/bugzilla/show_bug.cgi?id=16833 (A Solaris developer requested this in 2014) (This can be useful to RISC-V .gcc_except_table, so I am CCing Nelson here: https://reviews.llvm.org/D83655 GCC uses .gcc_except_table.function_name in a COMDAT group, the 'function_name' part is however a bit tricky to implement in clang. It also waste .strtab space. The "o" key, similar to the "G" key, can differentiate two sections .section .gcc_except_table,"ao",@progbits,.Z3foov .section .gcc_except_table,"ao",@progbits,.Z3barv ) Dancing with overloaded semantics of SHF_LINK_ORDER is not the most elegant thing, but in the absence of a new section flag we have to these kind of stuff (some are probably already done by Solaris ld). Designing a new section flag may still be considered premature currently. We might not be able to sort out all the implications (https://reviews.llvm.org/D72904#2192452 ) Playing with GC semantics+SHF_LINK_ORDER may not be favored by some ELF purists ("Why not section group?") but the object file size factor cannot really be neglected. Sanitizer folks will continue leveraging SHF_LINK_ORDER.
- Previous message (by thread): [PATCH] bpf: relocation fixes for eBPF ELF backend
- Next message (by thread): ld: Why does ppc64 have --no-toc-optimize instead of reusing --no-relax?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Binutils mailing list