This is the mail archive of the
mailing list for the binutils project.
Re: [RFC] [MIPS] Enable non-executable PT_GNU_STACK support v2
- From: Aaro Koskinen <aaro dot koskinen at iki dot fi>
- To: "Maciej W. Rozycki" <macro at imgtec dot com>
- Cc: binutils at sourceware dot org, Faraz Shahbazker <faraz dot shahbazker at imgtec dot com>, Joseph Myers <joseph at codesourcery dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, Aurelien Jarno <aurelien at aurel32 dot net>
- Date: Thu, 22 Dec 2016 03:12:26 +0200
- Subject: Re: [RFC] [MIPS] Enable non-executable PT_GNU_STACK support v2
- Authentication-results: sourceware.org; auth=none
- References: <56A15768.email@example.com> <56A157AF.firstname.lastname@example.org> <alpine.DEB.email@example.com> <56A6BF93.firstname.lastname@example.org> <56B4EC43.email@example.com> <20160811210118.GA5342@aurel32.net> <firstname.lastname@example.org> <alpine.DEB.email@example.com>
On Thu, Dec 22, 2016 at 12:52:41AM +0000, Maciej W. Rozycki wrote:
> On Thu, 22 Dec 2016, Aaro Koskinen wrote:
> > On Thu, Aug 11, 2016 at 11:01:18PM +0200, Aurelien Jarno wrote:
> > > On 2016-02-05 10:38, Faraz Shahbazker wrote:
> > > > Bump!
> > > >
> > > > Related patches for review:
> > > > * binutils: https://sourceware.org/ml/libc-alpha/2016-01/msg00567.html
> > > > * gcc : https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00444.html
> > > >
> > >
> > > It seems that the patches are present in the 2.27 binutils release,
> > > while they are not yet ready on the glibc side (I guess still waiting
> > > on the IFUNC patches).
> > >
> > > This means that building binaries with -Wl,-z,noexecstack set the ABI
> > > version to 5 and we then have no way to execute them. Some configure
> > > scripts probe for the availability of this option and enable it
> > > automatically.
> > Would it be possible to revert (or provide option to disable) these
> > changes in binutils 2.28?
> Making PT_GNU_STACK executables stop working with legacy glibc which
> does not support the feature required is IIUC the whole point of the
> binutils change, so it serves its purpose AFAICT.
Maybe, but today only "legacy glibc" exists and people have no way
of knowing or preparing for that when taking new binutils into use. I
don't think it's good a practice to make a release that depends on some
imaginary future version of some other software component. At least it's
not very pragmatic.