On Mon, Nov 09, 2020 at 10:36:07AM -0800, H.J. Lu via Gcc-patches wrote:
> On Mon, Nov 9, 2020 at 9:41 AM Jozef Lawrynowicz
> <joze...@mittosystems.com> wrote:
> >
> > On Fri, Nov 06, 2020 at 04:39:33PM -0800, H.J. Lu via Gcc-patches wrote:
> > > On Fri, Nov 6, 2020 at 4:17 PM Jeff Law <l...@redhat.com> wrote:
> > > >
> > > >
> > > > On 11/6/20 5:13 PM, H.J. Lu wrote:
> > > > > On Fri, Nov 6, 2020 at 4:01 PM Jeff Law <l...@redhat.com> wrote:
> > > > >>
> > > > >> On 11/6/20 4:45 PM, H.J. Lu wrote:
> > > > >>> On Fri, Nov 6, 2020 at 3:37 PM Jeff Law <l...@redhat.com> wrote:
> > > > >>>> On 11/6/20 4:29 PM, H.J. Lu wrote:
> > > > >>>>> On Fri, Nov 6, 2020 at 3:22 PM Jeff Law <l...@redhat.com> wrote:
> > > > >>>>>> On 11/5/20 7:34 AM, H.J. Lu via Gcc-patches wrote:
> > > > >>>>>>> On Thu, Nov 5, 2020 at 3:37 AM Jozef Lawrynowicz
> > > > >>>>>>> <joze...@mittosystems.com> wrote:
> > > > >>>>>>>> On Thu, Nov 05, 2020 at 06:21:21AM -0500, Hans-Peter Nilsson
> > > > >>>>>>>> wrote:
> > > > >>>>>>>>> On Wed, 4 Nov 2020, H.J. Lu wrote:
> > > > >>>>>>>>>> .retain is ill-defined. For example,
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> [hjl@gnu-cfl-2 gcc]$ cat /tmp/x.c
> > > > >>>>>>>>>> static int xyzzy __attribute__((__used__));
> > > > >>>>>>>>>> [hjl@gnu-cfl-2 gcc]$ ./xgcc -B./ -S /tmp/x.c -fcommon
> > > > >>>>>>>>>> [hjl@gnu-cfl-2 gcc]$ cat x.s
> > > > >>>>>>>>>> .file "x.c"
> > > > >>>>>>>>>> .text
> > > > >>>>>>>>>> .retain xyzzy <<<<<<<<< What does it do?
> > > > >>>>>>>>>> .local xyzzy
> > > > >>>>>>>>>> .comm xyzzy,4,4
> > > > >>>>>>>>>> .ident "GCC: (GNU) 11.0.0 20201103 (experimental)"
> > > > >>>>>>>>>> .section .note.GNU-stack,"",@progbits
> > > > >>>>>>>>>> [hjl@gnu-cfl-2 gcc]$
> > > > >>>>>>>>> To answer that question: it's up to the assembler, but for ELF
> > > > >>>>>>>>> and SHF_GNU_RETAIN, it seems obvious it'd tell the assembler
> > > > >>>>>>>>> to
> > > > >>>>>>>>> set SHF_GNU_RETAIN for the section where the symbol ends up.
> > > > >>>>>>>>> We both know this isn't rocket science with binutils.
> > > > >>>>>>>> Indeed, and my patch handles it trivially:
> > > > >>>>>>>> https://sourceware.org/pipermail/binutils/2020-November/113993.html
> > > > >>>>>>>>
> > > > >>>>>>>> +void
> > > > >>>>>>>> +obj_elf_retain (int arg ATTRIBUTE_UNUSED)
> > > > >>>>>>>> .... snip ....
> > > > >>>>>>>> + sym = get_sym_from_input_line_and_check ();
> > > > >>>>>>>> + symbol_get_obj (sym)->retain = 1;
> > > > >>>>>>>>
> > > > >>>>>>>> @@ -2624,6 +2704,9 @@ elf_frob_symbol (symbolS *symp, int
> > > > >>>>>>>> *puntp)
> > > > >>>>>>>> }
> > > > >>>>>>>> }
> > > > >>>>>>>>
> > > > >>>>>>>> + if (symbol_get_obj (symp)->retain)
> > > > >>>>>>>> + elf_section_flags (S_GET_SEGMENT (symp)) |=
> > > > >>>>>>>> SHF_GNU_RETAIN;
> > > > >>>>>>>> +
> > > > >>>>>>>> /* Double check weak symbols. */
> > > > >>>>>>>> if (S_IS_WEAK (symp))
> > > > >>>>>>>> {
> > > > >>>>>>>>
> > > > >>>>>>>> We could check that the symbol named in the .retain directive
> > > > >>>>>>>> has
> > > > >>>>>>>> already been defined, however this isn't compatible with GCC
> > > > >>>>>>>> mark_decl_preserved handling, since mark_decl_preserved is
> > > > >>>>>>>> called
> > > > >>>>>>>> emitted before the local symbols are defined in the assembly
> > > > >>>>>>>> output
> > > > >>>>>>>> file.
> > > > >>>>>>>>
> > > > >>>>>>>> GAS should at least validate that the symbol named in the
> > > > >>>>>>>> .retain
> > > > >>>>>>>> directive does end up as a symbol though.
> > > > >>>>>>>>
> > > > >>>>>>> Don't add .retain.
> > > > >>>>>> Why? I don't see why you find it so objectionable.
> > > > >>>>>>
> > > > >>>>> An ELF symbol directive should operate on symbol table:
> > > > >>>>>
> > > > >>>>> http://www.sco.com/developers/gabi/latest/ch4.symtab.html
> > > > >>>>>
> > > > >>>>> not the section flags where the symbol is defined.
> > > > >>>> I agree in general, but I think this is one of those cases where
> > > > >>>> it's
> > > > >>>> not so clear. And what you're talking about is an implementation
> > > > >>>> detail.
> > > > >>> There is no need for such a hack. The proper thing to do in ELF is
> > > > >>> to place such a symbol in a section with SHF_GNU_RETAIN flag. This
> > > > >>> also avoids the question what to do with SHN_COMMON.
> > > > >> I'm not sure that's a good idea either. Moving symbols into a
> > > > >> section
> > > > >> other than they'd normally live doesn't seem all that wise.
> > > > > In ELF, a symbol must be defined in a section. If we want to keep a
> > > > > symbol,
> > > > > we should place it in an SHF_GNU_RETAIN section.
> > > >
> > > > Again, that's an implementation detail and it's not clear to me that one
> > > > approach is inherently better than the other.
> > > >
> > > >
> > > > >
> > > > >> Let's face it, there's not a great solution here. If we mark its
> > > > >> existing section, then everything in that section gets kept. If we
> > > > >> put
> > > > > FWIW, this is what .retain direct does and is one reason why I object
> > > > > it.
> > > >
> > > > We could make .retain work with either approach. I don't see .retain
> > > > as a problem at all.
> > > >
> > > >
> > > >
> > > > >
> > > > >> the object into a different section than it would normally live, then
> > > > >> that opens a whole new can of worms.
> > > > > We should place it in a section which it normally lives in and mark
> > > > > the
> > > > > section with SHF_GNU_RETAIN.
> > > >
> > > > And why not do that with .retain? We define its semantics as precisely
> > >
> > > But the .retain directive implementation being discussed here is
> > > different.
> > > One problem with the .retain directive is we can have
> > >
> > > .section .data
> > > foo:
> > > ...
> > > bar:
> > >
> > > .retain bar
> > > ...
> > > xxx:
> > > ...
> > >
> > > What should assembler do with ".retain bar"?
> > >
> > > > what you've written above. The referenced symbol goes into its usual
> > > > section and its section is marked with SHF_GNU_RETAIN. That seems much
> > > > cleaner than having to track all this in the compiler so that it can
> > > > twiddle the section flags.
> > >
> > > When GCC emits a symbol definition, it places the symbol in a section
> > > with proper
> > > attributes which GCC tracks for each symbol. It can be extended to track
> > > SHF_GNU_RETAIN.
> >
> > The attached patch is rough around the edges but shows my approach for
> > marking unnamed sections as retained, by converting them to named
> > sections.
> >
> > I figure we don't have to wrap every usage of SECTION_RETAIN in
> > HAVE_GAS_SECTION_RETAIN as long as any set of SECTION_RETAIN in the
> > flags field is wrapped in the macro.
> >
> > I think a flag to turn off the behavior (in the same way the behavior is
> > disabled if !defined(HAVE_GAS_SECTION_RETAIN)) would be beneficial,
> > I haven't added that yet.
> >
> > Decls that would go in comm_section, tls_comm_section and sometimes
> > lcomm_section do not get retained as we can't apply the retain section
> > flag to these symbols. Given these go in one big common block, and
> > contain uninitialized data, I don't think there is a valid use case for
> > which these types of symbols need to be retained, but are not referenced
> > by the program. So I've avoided converting them to .bss or anything like
> > that.
> >
> > Some targets alias lcomm_section for bss_section, so we can retain
> > sections for that case.
> >
> > So far bootstrap and light testing on x86_64-pc-linux-gnu and
> > arm-none-eabi has shown no problems.
> >
>
> Binutils change looks OK. But GCC changes look too intrusive.
> Also SHF_GNU_RETAIN can't be used on Solaris since ld on
> Solaris may not support it.
I see Solaris ELF OSABI doesn't get set in bfd/elf32-i386.c because:
/* Restore default: we cannot use ELFOSABI_SOLARIS, otherwise ELFOSABI_NONE
objects won't be recognized. */
#undef ELF_OSABI
Since GNU OSABI support is implied for ELFOSABI_NONE, I guess there
needs to be an exception for the "R" section flag support where we check
if the target OS is Solaris.
>
> Can you improve
>
> https://gitlab.com/x86-gcc/gcc/-/tree/users/hjl/elf/shf_retain
>
> to do what you need?
I don't want "used" to implicitly create named sections for decls which
would otherwise just be placed in the standard .text/.data/.rodata/.bss
sections.
Unless we just ignore the requirement to "retain" for unnamed sections,
something like my patch is needed where we transform assembler output
from
.text -> .section .text,"axR"
or
.bss -> .section .bss,"awR"
etc.
Jozef
>
> --
> H.J.
