This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH, MIPS] Ensure PT_MIPS_ABIFLAGS is not introduced by objcopy/strip
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- Cc: "binutils\ at sourceware dot org" <binutils at sourceware dot org>, Robert Schiele <rschiele at gmail dot com>
- Date: Thu, 23 Jul 2015 23:03:31 +0100
- Subject: Re: [PATCH, MIPS] Ensure PT_MIPS_ABIFLAGS is not introduced by objcopy/strip
- Authentication-results: sourceware.org; auth=none
- References: <6D39441BF12EF246A7ABCE6654B02353211E7B5D at LEMAIL01 dot le dot imgtec dot org>
Matthew Fortune <Matthew.Fortune@imgtec.com> 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
> 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)).