On Tue, Nov 03, 2020 at 09:57:58AM -0800, H.J. Lu via Gcc-patches wrote: > On Tue, Nov 3, 2020 at 9:41 AM Jozef Lawrynowicz > <joze...@mittosystems.com> wrote: > > > > The attached patch implements TARGET_ASM_MARK_DECL_PRESERVED for ELF GNU > > OSABI targets, so that declarations that have the "used" attribute > > applied will be saved from linker garbage collection. > > > > TARGET_ASM_MARK_DECL_PRESERVED will emit an assembler ".retain" > > Can you use the "R" flag instead? >
For the benefit of this mailing list, I have copied my response from the Binutils mailing list regarding this. The "comm_section" example I gave is actually innacurate, but you can see the examples of the variety of sections that would need to be handled by doing $ git grep -A2 "define.*SECTION_ASM_OP" gcc/ | grep "\".*\." > ... snip ... > Secondly, for seamless integration with the "used" attribute, we must be > able to to mark the symbol with the used attribute applied as "retained" > without changing its section name. For GCC "named" sections, this is > straightforward, but for "unnamed" sections it is a giant mess. > > The section name for a GCC "unnamed" section is not readily available, > instead a string which contains the full assembly code to switch to one > of these text/data/bss/rodata/comm etc. sections is encoded in the > structure. > > Backends define the assembly code to switch to these sections (some > "*ASM_OP*" macro) in a variety of ways. For example, the unnamed section > "comm_section", might correspond to a .bss section, or emit a .comm > directive. I even looked at trying to parse them to extract what the > name of a section will be, but it would be very messy and not robust. > > Meanwhile, having a .retain <symbol_name> directive is a very simmple > solution, and keeps the GCC implementation really concise (patch > attached). The assembler will know for sure what the section containing > the symbol will be, and can apply the SHF_GNU_RETAIN flag directly. > > Finally, having a .retain directive means that we don't need to support > multiple sections with the same name, but different states for the "R" > flag. For example, and Fangrui raised this point in previous discussion, > the following is undesirable, as it violates the rule we have about > section flags set in .section directives being the same for sections of > the same name: > > .section .text,"ax",%progbits > ... > .section .text,"axR",%progbits > .... > > > The above would be required if GCC can only mark decls are retained by > explicitly placing them in a section with the SHF_GNU_RETAIN flag > applied. The .retain <symbol_name> directive greatly simplifies the > process for GCC. > > directive for the decl, and the assembler will apply the SHF_GNU_RETAIN > > flag to the section containing the decl. > > The linker will not garbage collect sections marked with the > > SHF_GNU_RETAIN flag. > > > > SHF_GNU_RETAIN is a GNU OSABI ELF extension, and it was discussed on the > > GNU gABI mailing list here: > > https://sourceware.org/pipermail/gnu-gabi/2020q3/000429.html > > > > The Binutils patch to implement .retain and other SHF_GNU_RETAIN > > handling is posted here: > > https://sourceware.org/pipermail/binutils/2020-November/113993.html > > > > Successfully bootstrapped and regtested for x86_64-pc-linux-gnu, and > > regtested for arm-none-eabi. > > > > Ok for trunk? > > > > Thanks, > > Jozef > > > > -- > H.J.
