On Tue, Nov 3, 2020 at 10:22 AM Jozef Lawrynowicz <joze...@mittosystems.com> wrote: > > 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. > >
Please take a look at https://gitlab.com/x86-gcc/gcc/-/commits/users/hjl/elf/shf_retain which is built in top of https://gcc.gnu.org/pipermail/gcc-patches/2020-February/539963.html I think SECTION2_RETAIN matches SHF_GNU_RETAIN well. If you want, you extract my flags2 change and use it for SHF_GNU_RETAIN. -- H.J.
