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

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Fri, Jan 12, 2018 at 12:44 AM, Alan Modra <amodra@gmail.com> wrote:
> 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?

Good points.  Let leave zero padding here.

-- 
H.J.