On Wed, Nov 4, 2020 at 1:03 PM Hans-Peter Nilsson <h...@bitrange.com> wrote: > > On Wed, 4 Nov 2020, H.J. Lu wrote: > > On Wed, Nov 4, 2020 at 10:09 AM Hans-Peter Nilsson <h...@bitrange.com> > > wrote: > > > > > > On Wed, 4 Nov 2020, Jozef Lawrynowicz wrote: > > > > I personally do not see the problem with the .retain attribute, however > > > > if it is going to be a barrier to getting the functionality committed, I > > > > am happy to change it, since I really just want the functionality in > > > > upstream sources. > > > > > > > > If a global maintainer would comment on whether any of the proposed > > > > approaches are acceptable, then I will try to block out time from other > > > > deadlines so I can work on the fixups and submit a patch in time for the > > > > GCC 11 freeze. > > > > > > > > Thanks, > > > > Jozef > > > > > > I'm not much more than a random voice, but an assembly directive > > > that specifies the symbol (IIUC your .retain directive) to > > > > But .retain directive DOES NOT adjust symbol attribute. Instead, it sets > > the SHF_GNU_RETAIN bit on the section which contains the symbol > > definition. The same section can have many unrelated symbols. > > That's an implementation detail *left to the assembler and > linker*. It's not something the compiler needs to know, and > teoretically it could even change. >
The ELF extension is SHF_GNU_RETAIN. .retain directive is a hack which I strongly objected and showed that it wasn't needed to implement SHF_GNU_RETAIN in binutils. -- H.J.
