Re: Bug#834096: binutils: produce unexecutable MIPS binaries with -Wl,-z,noexecstack
On 2016-08-11 23:48, Aurelien Jarno wrote:
> On 2016-08-11 23:45, Aurelien Jarno wrote:
> > On 2016-08-11 23:12, Aurelien Jarno wrote:
> > > Package: binutils
> > > Version: 2.27-4
> > > Severity: serious
> > >
> > > Dear Maintainer,
> > >
> > > binutils 2.27 added support for non-executable PT_GNU_STACK on mips. For
> > > that it sets the ABI version to 5 in the ELF headers so that the glibc
> > > can set the stack permission accordingly. Unfortunately the glibc part
> > > hasn't been merged yet. This means that binaries produced with
> > > -Wl,-z,noexecstack can't be executed later. This is the reason why
> > > ffmpeg failed to build from source.
> > >
> > > I guess we should disabled non-executable PT_GNU_STACK on mips until we
> > > get full glibc support. I'll try to work on a patch in the next days,
> > > but given my time is currently a bit limited, any help would be
> > > appreciated.
> >
> > The attached patch should do it. It's basically a revert of the upstream
> > commit, so that should work. I haven't tested it yet, I will do it
> > tomorrow.
>
> The patch...
>
> --
> Aurelien Jarno GPG: 4096R/1DDD8C9B
> aurelien@aurel32.net http://www.aurel32.net
> # DP: do not set the ABIVERSION to 5 for MIPS objects with non-executable stack
>
> This is basically a revert of upstream commit 17733f5be9. The GNU libc
> side is not yet ready for that.
>
> --- a/bfd/elfxx-mips.c
> +++ b/bfd/elfxx-mips.c
> @@ -16187,9 +16187,6 @@
> if (mips_elf_tdata (abfd)->abiflags.fp_abi == Val_GNU_MIPS_ABI_FP_64
> || mips_elf_tdata (abfd)->abiflags.fp_abi == Val_GNU_MIPS_ABI_FP_64A)
> i_ehdrp->e_ident[EI_ABIVERSION] = 3;
> -
> - if (elf_stack_flags (abfd) && !(elf_stack_flags (abfd) & PF_X))
> - i_ehdrp->e_ident[EI_ABIVERSION] = 5;
> }
>
> int
I confirm the above patch fixes the problem. Matthias, could you please
do an upload of binutils with it? Thanks in advance.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: