SHF_LINK_ORDER's original semantics make upgrade difficult

Fangrui Song maskray@google.com
Thu Aug 6 05:33:09 GMT 2020


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.


More information about the Binutils mailing list