Re: [PATCH] alpha: reallocate .got contents when relaxation grows a subsection

On Fri, Aug 14, 2026 at 04:25:38PM -0400, Matt Turner wrote:
> @@ -3726,12 +3779,18 @@ elf64_alpha_relax_section (bfd *abfd, asection *sec,
>        htab->relax_trip = link_info->relax_trip;
>  
>        /* This should never fail after the initial round, since the only error
> -	 is GOT overflow, and relaxation only shrinks the table.  However, we
> -	 may only merge got sections during the first pass.  If we merge
> -	 sections after we've created GPREL relocs, the GP for the merged
> -	 section backs up which may put the relocs out of range.  */
> +	 is GOT overflow, and relaxation only shrinks the table overall.
> +	 However, we may only merge got sections during the first pass.  If
> +	 we merge sections after we've created GPREL relocs, the GP for the
> +	 merged section backs up which may put the relocs out of range.  */
>        if (!elf64_alpha_size_got_sections (link_info, relax_pass == 0))
>  	abort ();
> +
> +      /* A re-merge can still grow an individual subsection, even though
> +	 the table as a whole shrinks, so the contents allocated by
> +	 elf64_alpha_early_size_sections may no longer be big enough.  */
> +      if (!elf64_alpha_realloc_got_contents (link_info))
> +	return false;

The above happens once per relaxation pass.  I'm a little concerned
that elf64_alpha_realloc_got_contents throws away previously allocated
memory.  (It can't do anything else with bfd_alloc memory.)  You say
"we may only merge got sections during the first pass".  Is that
really true?  If not, then it may be better to bfd_malloc/bfd_realloc
that memory.

-- 
Alan Modra