On Thu, 2020-01-23 at 10:58 +0000, Dragan Mladjenovic wrote: > On 07.12.2019. 19:33, Jeff Law wrote: > > On Thu, 2019-11-07 at 17:05 +0000, Dragan Mladjenovic wrote: > > > On 01.11.2019. 11:32, Dragan Mladjenovic wrote: > > > > On 10.08.2019. 00:15, Joseph Myers wrote: > > > > > On Fri, 9 Aug 2019, Jeff Law wrote: > > > > > > > > > > > > 2019-08-05 Dragan Mladjenovic <dmladjeno...@wavecomp.com> > > > > > > > > > > > > > > * config.in: Regenerated. > > > > > > > * config/mips/linux.h (NEED_INDICATE_EXEC_STACK): Define > > > > > > > to 1 > > > > > > > for TARGET_LIBC_GNUSTACK. > > > > > > > * configure: Regenerated. > > > > > > > * configure.ac: Define TARGET_LIBC_GNUSTACK if glibc > > > > > > > version is > > > > > > > found 2.31 or greater. > > > > > > My only concern here is the configure bits. So for example, > > > > > > will it do > > > > > > the right thing if you're cross-compiling to a MIPS linux > > > > > > target? If > > > > > > so, how? If not, do we need to make it a first class configure > > > > > > option > > > > > > so that it can be specified when building cross MIPS linux > > > > > > toolchains? > > > > > > > > > > The key point of using GCC_GLIBC_VERSION_GTE_IFELSE is that (a) > > > > > it checks > > > > > the target glibc headers if available when GCC is built and (b) > > > > > if not > > > > > available, you can still use --with-glibc-version when > > > > > configuring > > > > > GCC, to > > > > > get the right configuration in a bootstrap compiler built before > > > > > glibc is > > > > > built (the latter is necessary on some architectures to get the > > > > > right > > > > > stack-protector configuration for bootstrapping glibc, but may be > > > > > useful > > > > > in other cases as well). > > > > > > > > > > My main concern about this patch is the one I gave in > > > > > <https://sourceware.org/ml/libc-alpha/2019-08/msg00086.html> > > > > > about what > > > > > the configuration mechanism should be, on a whole-toolchain > > > > > level, to say > > > > > whether you are OK with a requirement for a 4.8 or later kernel. > > > > > > > > > > > > > Sorry for the late reply. > > > > > > > > I was waiting to backport [1] to most of the glibc release branches > > > > in > > > > use, but I got sidetracked along the way. > > > > > > > > After this patch lands the preferred way to configure gcc would be > > > > using > > > > --with-glibc-version=2.31 and to use said glibc. > > > > If the user/distribution can live with minimal kernel requirement > > > > of 4.8 > > > > the glibc used should be configured with --enable-kernel=4.8. > > > > I also plan to backport the [1] to limit the opportunity for > > > > building > > > > the possibly broken glibc with the gcc w/ enabled .note.GNU-stack. > > > > > > > > This is all tedious and user has to be aware of all of it to make > > > > it > > > > work, but hopefully over time the distributions will default to > > > > --with-glibc-version=2.31 and --enable-kernel=4.8. I guess > > > > providing the > > > > detailed NEWS entry for this change would help a bit. > > > > > > > > Is there any objections to getting this on the trunk before the end > > > > of > > > > stage1? > > > > > > > > [1] https://sourceware.org/ml/libc-alpha/2019-08/msg00639.html > > > > > > > > > > Small update and gentle ping. The glibc change was backported all > > > the > > > way back to 2.24. > > I think this is fine. And yes, we'd like to get it mentioned in the > > release notes since I suspect folks will want the GNU-stack ELF notes. > > > > jeff > > > > > > I left this to fall through the cracks once again. In light of [1], is > there any leeway for me to push this now? > > [1] https://gcc.gnu.org/ml/gcc/2020-01/msg00199.html We generally allow more leeway for the ports simply because getting something wrong doesn't have as wide an impact. Additionally, you're using a configure-time flag to turn on the new behavior which further limits the impact if something were to go wrong.
So if you want to commit it now, go ahead jeff > >