[PATCH, MIPS] Ensure PT_MIPS_ABIFLAGS is not introduced by objcopy/strip

[Richard Sandiford]

Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
> Bug fix following on from this report:
> https://sourceware.org/ml/binutils/2015-07/msg00168.html
>
> The PT_MIPS_ABIFLAGS header is unconditionally introduced if
> a .MIPS.abiflags section is found.  This is OK for final linking
> but it is possible to create an executable with a .MIPS.abiflags
> section but without PT_MIPS_ABIFLAGS.  To create such a binary
> in a real world environment then:
>
> 1) Take an object built with gas that has support for .MIPS.abiflags
> 2) Link this object using a linker that does NOT have support for
>    .MIPS.abiflags
> 3) Objcopy or strip the resulting binary with a binutils that
>    does have support for .MIPS.abiflags
>
> The fix (I think) is to rely on objcopy's duplication of all PHDRs and
> not introduce one when there is no link information. Existing entries
> will therefore be retained but the PHDR section will not need
> to grow.

Playing devil's advocate here, but is this really a supported combination?
AIUI the linker won't handle .MIPS.abiflags correctly, so the linked output
is still not going to be correct (in the eyes of (3)).

Thanks,
Richard