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

[Alan Modra]

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.

> --- 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.

-- 
Alan Modra
Australia Development Lab, IBM