This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Matthew Fortune <> writes:
> Bug fix following on from this report:
> 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)).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]