This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [RFC] [MIPS] Enable non-executable PT_GNU_STACK support v2
- From: Joseph Myers <joseph at codesourcery dot com>
- To: "Maciej W. Rozycki" <macro at imgtec dot com>
- Cc: Aaro Koskinen <aaro dot koskinen at iki dot fi>, <binutils at sourceware dot org>, Faraz Shahbazker <faraz dot shahbazker at imgtec 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 01:07:50 +0000
- Subject: Re: [RFC] [MIPS] Enable non-executable PT_GNU_STACK support v2
- Authentication-results: sourceware.org; auth=none
- References: <56A15768.20005@imgtec.com> <56A157AF.8080504@imgtec.com> <alpine.DEB.2.10.1601212215030.24424@digraph.polyomino.org.uk> <56A6BF93.5010401@imgtec.com> <56B4EC43.7040000@imgtec.com> <20160811210118.GA5342@aurel32.net> <20161222003609.3fdfjx6at2f5ffuv@raspberrypi-2.musicnaut.iki.fi> <alpine.DEB.2.00.1612220042030.6743@tp.orcam.me.uk>
On Thu, 22 Dec 2016, Maciej W. Rozycki wrote:
> 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. I can revert the
> change, but before I do it can someone please tell me why can't MIPS
> support for PT_GNU_STACK be simply pushed to glibc instead? And what's
> the relevance of the IFUNC feature here (which will now use ABI version
> 6, the next available one) -- is there a functional dependency between
> the glibc side of these two features?
I thought 4 was reserved for IFUNC, meaning that support for 5 implied
support for IFUNC (because a simple comparison is all that's available to
tell whether glibc supports the features required by an executable /
shared library; it's a single ABI version number, not a bitmask of
features used) and so the ordering was forced. Certainly the patch here
lists IFUNC before MIPS_GNU_STACK, and I don't think the libc-abis system
supports gaps in the numbering (you'd need to put in a dummy name if 4 is
now to be unused, but then the dummy name would be visible when you run
libc.so.6, which it shouldn't be).
Has a non-RFC patch posting for glibc for this feature been made? If it's
to get in glibc someone will need to post a patch tested against current
glibc - with the architecture-independent pieces posted separately from
the MIPS-specific pieces, please, as they are likely to be reviewed
separately, making sure to include self-contained rationale and pointers
to any relevant ABIs, information about kernel, GCC, binutils support,
etc. (I'd suggest updating the comment on the XFAIL in
sysdeps/unix/sysv/linux/mips/Makefile to give concrete information about
the specific versions of GCC and binutils needed for the test to pass /
kernel version needed for no-exec stack support to work properly - I mean
upstream mainline versions, any references to uncommitted or non-mainline
patches need to be clear about their status). Even then, it seems
unlikely you'll get review in time for 2.25, i.e. by 31 December (and you
may need to keep pinging weekly); I don't know how many dynamic linker
experts we have to review the design of the architecture-independent
pieces.
--
Joseph S. Myers
joseph@codesourcery.com