[PATCH] ld: Pad the previous code segment with NOPs

[Alan Modra]

On Thu, Jan 11, 2018 at 07:25:14PM -0800, H.J. Lu wrote:
> @@ -5429,6 +5431,28 @@ assign_file_positions_for_load_sections (bfd *abfd,
>  	      && (off & -maxpagesize) == ((off + off_adjust) & -maxpagesize))
>  	    off_adjust += maxpagesize;
>  	  off += off_adjust;
> +
> +	  if (off_adjust != 0
> +	      && j > 1
> +	      && p[-1].p_filesz != 0
> +	      && (p[-1].p_flags & PF_X) != 0)
> +	    {
> +	      /* Pad the previous code segment with NOPs.  */
> +	      char *fill = abfd->arch_info->fill (off_adjust,
> +						  bfd_big_endian (abfd),
> +						  TRUE);
> +	      if (fill == NULL
> +		  || bfd_seek (abfd, off_prev_end, SEEK_SET) != 0
> +		  || bfd_bwrite (fill, off_adjust, abfd) != off_adjust)
> +		{
> +		  _bfd_error_handler
> +		    (_("%B: failed to pad code segment %d"), j - 1, abfd);
> +		  return FALSE;
> +		}
> +
> +	      free (fill);
> +	    }
> +

Two things strike me as non-ideal here:

1) For targets that have arch_info->fill == bfd_arch_default_fill this
writes zeros to the output file, destroying a chance for the file to
be sparse.  ie. This patch may waste disk blocks.

2) The i386 fill function uses multi-byte nops.  Are any of those
patterns exploitable when executed at any offset from the start of the
insns?  Do other targets have the same potential problem?

-- 
Alan Modra
Australia Development Lab, IBM