* QA Notice: The following files contain writable and executable sections * Files with such sections will not work properly (or at all!) on some * architectures/operating systems. A bug should be filed at * http://bugs.gentoo.org/ to make sure the issue is fixed. * For more information, see http://hardened.gentoo.org/gnu-stack.xml * Please include the following list of files in your report: * Note: Bugs should be filed for the respective maintainers * of the package in question and not hardened@g.o. * !WX --- --- usr/lib64/nacl-toolchain-newlib/x86_64-nacl/lib32/libcrt_common.a:lib_a-memchr.o * !WX --- --- usr/lib64/nacl-toolchain-newlib/x86_64-nacl/lib32/libcrt_common.a:lib_a-memcmp.o * !WX --- --- usr/lib64/nacl-toolchain-newlib/x86_64-nacl/lib32/libcrt_common.a:lib_a-memcpy.o * !WX --- --- usr/lib64/nacl-toolchain-newlib/x86_64-nacl/lib32/libcrt_common.a:lib_a-memmove.o * !WX --- --- usr/lib64/nacl-toolchain-newlib/x86_64-nacl/lib32/libcrt_common.a:lib_a-memset.o * !WX --- --- usr/lib64/nacl-toolchain-newlib/x86_64-nacl/lib32/libcrt_common.a:lib_a-setjmp.o * !WX --- --- usr/lib64/nacl-toolchain-newlib/x86_64-nacl/lib32/libcrt_common.a:lib_a-strchr.o * !WX --- --- usr/lib64/nacl-toolchain-newlib/x86_64-nacl/lib32/libcrt_common.a:lib_a-strlen.o * !WX --- --- usr/lib64/nacl-toolchain-newlib/x86_64-nacl/lib32/libg.a:lib_a-memchr.o * !WX --- --- usr/lib64/nacl-toolchain-newlib/x86_64-nacl/lib32/libg.a:lib_a-memcmp.o * !WX --- --- usr/lib64/nacl-toolchain-newlib/x86_64-nacl/lib32/libg.a:lib_a-memcpy.o * !WX --- --- usr/lib64/nacl-toolchain-newlib/x86_64-nacl/lib32/libg.a:lib_a-memmove.o * !WX --- --- usr/lib64/nacl-toolchain-newlib/x86_64-nacl/lib32/libg.a:lib_a-memset.o * !WX --- --- usr/lib64/nacl-toolchain-newlib/x86_64-nacl/lib32/libg.a:lib_a-setjmp.o * !WX --- --- usr/lib64/nacl-toolchain-newlib/x86_64-nacl/lib32/libg.a:lib_a-strchr.o * !WX --- --- usr/lib64/nacl-toolchain-newlib/x86_64-nacl/lib32/libg.a:lib_a-strlen.o * !WX --- --- usr/lib64/nacl-toolchain-newlib/x86_64-nacl/lib32/libm.a:lib_a-f_atan2f.o * !WX --- --- usr/lib64/nacl-toolchain-newlib/x86_64-nacl/lib32/libm.a:lib_a-f_atan2.o * !WX --- --- usr/lib64/nacl-toolchain-newlib/x86_64-nacl/lib32/libm.a:lib_a-f_frexpf.o * !WX --- --- usr/lib64/nacl-toolchain-newlib/x86_64-nacl/lib32/libm.a:lib_a-f_frexp.o * !WX --- --- usr/lib64/nacl-toolchain-newlib/x86_64-nacl/lib32/libm.a:lib_a-f_ldexpf.o * !WX --- --- usr/lib64/nacl-toolchain-newlib/x86_64-nacl/lib32/libm.a:lib_a-f_ldexp.o * !WX --- --- usr/lib64/nacl-toolchain-newlib/x86_64-nacl/lib32/libm.a:lib_a-f_log10f.o * !WX --- --- usr/lib64/nacl-toolchain-newlib/x86_64-nacl/lib32/libm.a:lib_a-f_log10.o * !WX --- --- usr/lib64/nacl-toolchain-newlib/x86_64-nacl/lib32/libm.a:lib_a-f_logf.o * !WX --- --- usr/lib64/nacl-toolchain-newlib/x86_64-nacl/lib32/libm.a:lib_a-f_log.o * !WX --- --- usr/lib64/nacl-toolchain-newlib/x86_64-nacl/lib32/libm.a:lib_a-f_tanf.o * !WX --- --- usr/lib64/nacl-toolchain-newlib/x86_64-nacl/lib32/libm.a:lib_a-f_tan.o * !WX --- --- usr/lib64/nacl-toolchain-newlib/x86_64-nacl/lib/libcrt_common.a:lib_a-memcpy.o * !WX --- --- usr/lib64/nacl-toolchain-newlib/x86_64-nacl/lib/libcrt_common.a:lib_a-memset.o * !WX --- --- usr/lib64/nacl-toolchain-newlib/x86_64-nacl/lib/libcrt_common.a:lib_a-setjmp.o * !WX --- --- usr/lib64/nacl-toolchain-newlib/x86_64-nacl/lib/libg.a:lib_a-memcpy.o * !WX --- --- usr/lib64/nacl-toolchain-newlib/x86_64-nacl/lib/libg.a:lib_a-memset.o * !WX --- --- usr/lib64/nacl-toolchain-newlib/x86_64-nacl/lib/libg.a:lib_a-setjmp.o If is fixable, please do; otherwise, hide this QA notice =)
Created attachment 292387 [details] build.log
Those seem to correspond to functions which newlib implements in assembly language on i386. http://sourceware.org/cgi-bin/cvsweb.cgi/src/newlib/libc/machine/i386/?cvsroot=src From there, this is a bit over my head.
I think this is simply "case 3" in the GNU stack guide. http://www.gentoo.org/proj/en/hardened/gnu-stack.xml
Mike (vapier), could you help here? The problem seems to be newlib: x86_64-nacl-gcc -B/var/tmp/portage/dev-lang/nacl-toolchain-newlib-0_p6869-r1/work/BUILD/build-newlib-x86_64-nacl/x86_64-nacl/32/newlib/ -isystem /var/tmp/portage/dev-lang/nacl-toolchain-newlib-0_p6869-r1/work/BUILD/build-newlib-x86_64-nacl/x86_64-nacl/32/newlib/targ-include -isystem /var/tmp/portage/dev-lang/nacl-toolchain-newlib-0_p6869-r1/work/SRC/newlib/newlib/libc/include -m32 -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\" -DPACKAGE_VERSION=\"1.18.0\" -DPACKAGE_STRING=\"newlib\ 1.18.0\" -DPACKAGE_BUGREPORT=\"\" -I. -I../../../../../../../SRC/newlib/newlib/libc/string -DCLOCK_PROVIDED -DHAVE_NANOSLEEP -DMALLOC_PROVIDED -DMISSING_SYSCALL_NAMES -fno-builtin -O2 -D_I386MACH_ALLOW_HW_INTERRUPTS -DSIGNAL_PROVIDED -mtls-use-call -m32 -c -o lib_a-memcpy.o `test -f 'memcpy.c' || echo '../../../../../../../SRC/newlib/newlib/libc/string/'`memcpy.c I tried "append-flags -Wa,--noexecstack", but as you can see above it has no effect.
(In reply to comment #4) It looks like the build system ignores CFLAGS from the environment when building newlib. I think patching this will be ugly; it's a Google fork with lots of changes. Here are the compiler commands for memcpy.S (32 and 64 bit): x86_64-nacl-gcc -B/tmp/portage/dev-lang/nacl-toolchain-newlib-0_p6869-r1/work/BUILD/build-newlib-x86_64-nacl/x86_64-nacl/32/newlib/ -isystem /tmp/portage/dev-lang/nacl-toolchain-newlib-0_p6869-r1/work/BUILD/build-newlib-x86_64-nacl/x86_64-nacl/32/newlib/targ-include -isystem /tmp/portage/dev-lang/nacl-toolchain-newlib-0_p6869-r1/work/SRC/newlib/newlib/libc/include -m32 -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\" -DPACKAGE_VERSION=\"1.18.0\" -DPACKAGE_STRING=\"newlib\ 1.18.0\" -DPACKAGE_BUGREPORT=\"\" -I. -I../../../../../../../../SRC/newlib/newlib/libc/machine/i386 -I ../../../../../../../../SRC/newlib/newlib/libc/machine/i386/../../../libm/common -DCLOCK_PROVIDED -DHAVE_NANOSLEEP -DMALLOC_PROVIDED -DMISSING_SYSCALL_NAMES -fno-builtin -I ../../../../../../../../SRC/newlib/newlib/libc/machine/i386/../../../libm/common -DCLOCK_PROVIDED -DHAVE_NANOSLEEP -DMALLOC_PROVIDED -DMISSING_SYSCALL_NAMES -fno-builtin -O2 -D_I386MACH_ALLOW_HW_INTERRUPTS -DSIGNAL_PROVIDED -mtls-use-call -m32 -c -o lib_a-memcpy.o `test -f 'memcpy.S' || echo '../../../../../../../../SRC/newlib/newlib/libc/machine/i386/'`memcpy.S x86_64-nacl-gcc -B/tmp/portage/dev-lang/nacl-toolchain-newlib-0_p6869-r1/work/BUILD/build-newlib-x86_64-nacl/x86_64-nacl/newlib/ -isystem /tmp/portage/dev-lang/nacl-toolchain-newlib-0_p6869-r1/work/BUILD/build-newlib-x86_64-nacl/x86_64-nacl/newlib/targ-include -isystem /tmp/portage/dev-lang/nacl-toolchain-newlib-0_p6869-r1/work/SRC/newlib/newlib/libc/include -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\" -DPACKAGE_VERSION=\"1.18.0\" -DPACKAGE_STRING=\"newlib\ 1.18.0\" -DPACKAGE_BUGREPORT=\"\" -I. -I../../../../../../../SRC/newlib/newlib/libc/machine/x86_64 -DCLOCK_PROVIDED -DHAVE_NANOSLEEP -DMALLOC_PROVIDED -DMISSING_SYSCALL_NAMES -fno-builtin -DCLOCK_PROVIDED -DHAVE_NANOSLEEP -DMALLOC_PROVIDED -DMISSING_SYSCALL_NAMES -fno-builtin -O2 -D_I386MACH_ALLOW_HW_INTERRUPTS -DSIGNAL_PROVIDED -mtls-use-call -c -o lib_a-memcpy.o `test -f 'memcpy.S' || echo '../../../../../../../SRC/newlib/newlib/libc/machine/x86_64/'`memcpy.S
the executable section checks probably don't make sense for newlib code. i'd just disable the checks in your ebuild. see if something like this fixes it: QA_EXECSTACK=usr/lib*/nacl-toolchain-newlib/*/lib*/*
(In reply to comment #6) > the executable section checks probably don't make sense for newlib code. i'd > just disable the checks in your ebuild. > > see if something like this fixes it: > QA_EXECSTACK=usr/lib*/nacl-toolchain-newlib/*/lib*/* In CVS, thanks!
(In reply to comment #5) using system CFLAGS are probably a bad idea for building newlib. this code that gets packaged up and run inside the browser and distributed to all sorts of platforms. probably a lot saner to stick to what google is doing there.
*** Bug 406031 has been marked as a duplicate of this bug. ***
