[PATCH v3 4/9] ld: Initial DT_RELR support

[H.J. Lu]

On Tue, Jan 11, 2022 at 10:11 PM Alan Modra <amodra@gmail.com> wrote:
>
> On Tue, Jan 11, 2022 at 06:06:29AM -0800, H.J. Lu via Binutils wrote:
> > Add a -z pack-relative-relocs option to enable DT_RELR and create a
> > relr.dyn section for DT_RELR.  DT_RELR is implemented with the linker
> > relaxation infrastructure, but it doesn't require the --relax option
> > enabled.  -z pack-relative-relocs implies -z combreloc.  -z nocombreloc
> > implies -z nopack-relative-relocs.
>
> Like Fangrui, I think these options should not interact in this way.
> -z pack-relative-relocs -z combreloc
>   -> .relr.dyn for relative encoding, .rel{,a}.dyn for others
> -z pack-relative-relocs -z nocombreloc
>   -> .relr.dyn for relative encoding, .rela.<multiple sections> for others
>
> In other words, -z pack-relative-relocs overrides the place where
> RELATIVE dynrelocs go, other dynrelocs are still controlled by
> combreloc.

I removed the combreloc change.

> > --- a/ld/ldlang.c
> > +++ b/ld/ldlang.c
> > @@ -7699,7 +7699,8 @@ lang_find_relro_sections (void)
> >  void
> >  lang_relax_sections (bool need_layout)
> >  {
> > -  if (RELAXATION_ENABLED)
> > +  /* NB: Also enable relaxation to layout sections for DT_RELR.  */
> > +  if (RELAXATION_ENABLED || link_info.enable_dt_relr)
> >      {
> >        /* We may need more than one relaxation pass.  */
> >        int i = link_info.relax_pass;
>
> Also, this isn't correct.  You should instead arrange for relaxation
> to be enabled by the x86 target code.  Not every target that
> implements DT_RELR will want to use bfd_relax_section.  It might be
> true that this will do no harm for targets that currently use
> bfd_generic_relax_section (that does nothing) but it's still wrong
> to turn on relaxation like this.

I will push this one unchanged.   I don't want to change
RELAXATION_ENABLED for DT_RELR since RELAXATION_ENABLED
should be false in

lang_size_sections (NULL, !RELAXATION_ENABLED);

We improve it after my patches are checked in.

> --
> Alan Modra
> Australia Development Lab, IBM

Thanks.

-- 
H.J.