Summary: | dev-lang/nacl-toolchain-newlib-0_p6869-r1 contains WX sections | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Agostino Sarubbo <ago> |
Component: | New packages | Assignee: | Chromium Project <chromium> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | as.gentoo, vapier |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 390299 | ||
Attachments: | build.log |
Description
Agostino Sarubbo
2011-11-13 10:53:31 UTC
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. *** |