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: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Richard Sandiford <rdsandiford at googlemail 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 22:54:42 +0000
- 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> <871tfywmz0 dot fsf at googlemail dot com>
Richard Sandiford <firstname.lastname@example.org> writes:
> 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)).
Supported... not really. It was semi-intentionally left as undefined but since
the crash can be avoided we won't be making anything any worse by allowing
a weird ELF to be stripped or copied. In terms of the floating point ABI then
this will be probably safe as the gnu attributes should have been there in the
original link. Other data in the .MIPS.abiflags will of course have been
ignored and the sections will not have been merged in the original link so
could be quite large.
I just have a feeling that in the interim period while people move from one
set of tools to the next then this scenario may occur a fair bit until
the new tools are the norm. Inadvertently switching between tools seems
like it could happen. I suppose the fix could just be documented as needing
to remove the .MIPS.abiflags section if you hit this problem. I haven't
checked but I'd expect that would avoid generating the PT_MIPS_ABIFLAGS
header. My only concern if we were to document such a thing is that
removing .MIPS.abiflags may become common because it makes linking 'easier'
and then we end up with broken ELFs in the future.
Perhaps it would be useful to know the history of the ELF that led to this
Robert: Can you comment on how the offending ELF came to exist? I.e. Why the
two sets of binutils tools ended up being used?