Re: [PATCH] Support SHF_GNU_RETAIN ELF section flag

["H.J. Lu" <hjl.tools@gmail.com>]

On Wed, Sep 23, 2020 at 2:58 AM Jozef Lawrynowicz
<jozef.l@mittosystems.com> wrote:
>
> On Tue, Sep 22, 2020 at 07:24:01PM -0400, Hans-Peter Nilsson wrote:
> > On Tue, 22 Sep 2020, Jozef Lawrynowicz wrote:
> > > The new tests are passing for all targets except mmix-elf.
> >
> > There is no mmix-elf target: if it's buildable, that's a
> > mistake.  I'm not sure what kind of abomination results, if it's
> > a goldblum-fly or karloff-frankensteins. :)
> >
> > The target mmix a.k.a. mmix-knuth-mmixware assembles to ELF, but
> > links to MMO by use of the generic linker machinery.  You *can*
> > link to ELF by means of the linker option "-m elf64mmix".
> >
> > brgds, H-P
> >
>
> Ah, thanks for the info. I formed that list of targets by just
> extracting the CPU name from all the files in bfd/ with "elf" in the
> name.
>
> mmix-elf is buildable, and most tests pass, but it definitely appears
> that a lot is broken!
>
>   ==> mmix-elf/binutils.sum <==
>   # of expected passes            122
>   # of unexpected failures        38
>   ==> mmix-elf/gas.sum <==
>   # of expected passes            446
>   # of unexpected failures        68
>   ==> mmix-elf/ld.sum <==
>   # of expected passes            430
>   # of unexpected failures        158
>
> I'll remove any mmix-elf-specific XFAIL-ing from the patch.
>
> On Tue, Sep 22, 2020 at 04:58:23PM -0700, H.J. Lu via Binutils wrote:
> > On Tue, Sep 22, 2020 at 1:30 PM Jozef Lawrynowicz
> > <jozef.l@mittosystems.com> wrote:
> > >
> > +  /* A GNU extension for preventing linker garbage collection of sections.  */
> > +  {"retain", obj_elf_retain, 0},
> > +
> >
> > Why is this needed?  Isn't
> >
> > @@ -857,6 +861,9 @@ obj_elf_parse_section_letters (char *str, size_t len,
> >   case 'd':
> >    *gnu_attr |= SHF_GNU_MBIND;
> >    break;
> > + case 'R':
> > +  *gnu_attr |= SHF_GNU_RETAIN;
> > +  break;
> >   case '?':
> >    *is_clone = TRUE;
> >    break;
> >
> > enough?  The .section directive is used for all other SHF_XXX bits.   I don't
> > think we need a separate directive for SHF_GNU_RETAIN?
>
> GCC doesn't know if SHF_GNU_RETAIN is required when creating a section,
> since the "retain" attribute is applied to function and data
> declarations.
>
> So rather than emitting the section directive again, which could be
> confusing if there are two almost identical section declarations, the
> ".retain" directive describes the precise augmentation to make to the
> already-declared section.
>
> I think that:
>
> >  .section .text,"ax"
> >    ...
> >  foo:
> >    ...
> >  .retain
> >  retained_fn:
> >    ...
>
> is some nice syntactic sugar compared to:
>
> >  .section .text,"ax"
> >    ...
> >  foo:
> >    ...
> >  .section .text,"axR"
> >  retained_fn:
> >    ...
>
> It's also partly for convenience; we have other directives which are
> synonyms or short-hand for each other.
>

You don't need to keep the whole section when only one symbol should
be kept.  Please drop the .retain directive.  GCC, as and ld should do the
right thing with

.section .text,"ax"
   ...
foo:
  ...
 .section .text,"axR"

 retained_fn:

where foo can be dropped and retained_fn will be kept.

H.J.