Re: [PATCH] Support SHF_GNU_RETAIN ELF section flag

[Jozef Lawrynowicz <jozef.l@mittosystems.com>]

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.

There's a bug in my patch where a .section directive without the
"R" flag overrides an earlier .section directive for the same section
with the "R" flag and clobbers SHF_GNU_RETAIN, I need to fix that.

On Tue, Sep 22, 2020 at 06:09:30PM -0700, Fangrui Song wrote:
> On 2020-09-22, Jozef Lawrynowicz wrote:
> > The attached patch adds support for the new SHF_GNU_RETAIN ELF section
> > flag, which was discussed on the GNU gABI mailing list here:
> > https://sourceware.org/pipermail/gnu-gabi/2020q3/000429.html
> > 
> > The flag is GNU-specific so uses a bit in the SHF_MASKOS mask.
> > Its precise definition is as follows:
> 
> We already have a way to create an artificial reference:
> 
>   .reloc ., R_X86_64_NONE, target_symbol
> 
> If we allow a relocation number for the second operand
> 
>   .reloc ., 0, target_symbol
> 
> this will be generic. You can insert the directives in a GC root (e.g.
> _start or a symbol referenced by -u or maybe an .init_array)

I don't really understand how this would work in most cases when the
compiler or assembler aren't building the file which will contain the
eventual GC root. How are they to know what the GC root is anyway? What
if the assumed GC root changes after the files are built?

I also don't see any advantage of re-purposing .reloc for this use case,
over having a precisely defined new section flag. You would also have to
look at relocations defined in the GC root function (mixed with
relocations used for other purposes) to work out which sections are
being retained, instead of having retention being a property of the
section itself.

Thanks,
Jozef