Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
Building gnat-gcc-4.1.1 fails during the install stage with a Quality Assurance error as follows: QA Notice: the following files contain executable stacks Files with executable stacks 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 file is fixed. For more information, see http://hardened.gentoo.org/gnu-stack.xml Please include this file in your report: /mnt/hdb1/portage/tmp/portage/gnat-gcc-4.1.1/temp/scanelf-execstack.log "RWX --- --- usr/i686-pc-linux-gnu/gnat-gcc-bin/4.1/gnatbind" "RWX --- --- usr/i686-pc-linux-gnu/gnat-gcc-bin/4.1/gnatmake" "RWX --- --- usr/i686-pc-linux-gnu/gnat-gcc-bin/4.1/gnatls" "RWX --- --- usr/lib/gnat-gcc/i686-pc-linux-gnu/4.1/adalib/libgnat-4.1.so" "RWX --- --- usr/libexec/gnat-gcc/i686-pc-linux-gnu/4.1/gnat1" the aforementioned file (scanelf-execstack.log) contains: RWX --- --- work/usr/lib/gnatgcc/i686-pc-linux-gnu/4.1/adalib/libgnat-4.1.so RWX --- --- work/usr/bin/gnatbind RWX --- --- work/usr/bin/gnatmake RWX --- --- work/usr/bin/gnatls RWX --- --- work/usr/bin/gnat1 RWX --- --- work/build/gcc/ada/rts/libgnat-4.1.so RWX --- --- work/build/gcc/gnatbind RWX --- --- work/build/gcc/stage1/gnatbind RWX --- --- work/build/gcc/stage1/gnat1 RWX --- --- work/build/gcc/stage2/gnatbind RWX --- --- work/build/gcc/stage2/gnat1 RWX --- --- work/build/gcc/gnatmake RWX --- --- work/build/gcc/gnatls RWX --- --- work/build/gcc/gnat1 RWX --- --- image/usr/i686-pc-linux-gnu/gnat-gcc-bin/4.1/gnatbind RWX --- --- image/usr/i686-pc-linux-gnu/gnat-gcc-bin/4.1/gnatmake RWX --- --- image/usr/i686-pc-linux-gnu/gnat-gcc-bin/4.1/gnatls RWX --- --- image/usr/lib/gnat-gcc/i686-pc-linux-gnu/4.1/adalib/libgnat-4.1.so RWX --- --- image/usr/libexec/gnat-gcc/i686-pc-linux-gnu/4.1/gnat1 Only reading I found on the net refer to this problem in Ada as relating to GCC's trampolines which don't appear to be modifable in behaviour at compile time of packages. emerge --info: Portage 2.1-r1 (default-linux/x86/2006.0, gcc-4.1.1, glibc-2.3.6-r4, 2.6.16.19 i686) ================================================================= System uname: 2.6.16.19 i686 Intel(R) Celeron(R) CPU 2.60GHz Gentoo Base System version 1.6.15 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [disabled] app-admin/eselect-compiler: [Not Present] dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.3 dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -O1 -ffast-math -fomit-frame-pointer -freorder-blocks -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=pentium4 -O1 -ffast-math -fomit-frame-pointer -freorder-blocks -pipe" DISTDIR="/mnt/hdb1/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LC_ALL="en_US.UTF-8" LDFLAGS="-Wl,-z,now" LINGUAS="en en_GB ja ko ru zh_CN zh_TW" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/mnt/hdb1/portage/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 16bit 64bit X X509 a52 aac acl acpi ada aim alsa amarok amr amrr ansi asf atm audiofile authfile automount avahi bash-completion bcp bdf berkdb bidi big-tables binfilter bitmap-fonts bjam blas boehm-gc bzip2 c++ cairo cdb cddb cdf cdio cdr cdrom chasen chroot cjk cracklib crypt cscope css cups curl dbus dga dhcp directfb djbfft dlloader doc dpms dri dts dv dvd dvdr dvdread ecc edl encode enscript examples exif expat extensions extraengine extrafilters fam fbcon fdftk ffmpeg fftw finger firefox flac font-server foomaticdb fortran fpx ftp gcj geoip geometry gif gimp gimpprint glitz glut glx gmp gnutls gopher gpm graphviz gs gssapi gstreamer gtk2 hal haskell howl hpn iconv icq icu idn imagemagick imap imlib2 immqt-bc input_devices_keyboard input_devices_mouse ipv6 java javacomm javascript jbig jce jcs jikes jp2 jpeg jpeg2k junit justify kde kexi kig-scripting kipi kqemu latex lcms ldap ldapsam libg++ libwww lua lzo lzw m17n-lib maildir mailwrapper matroska max-idx-128 md5sum mhash migemo mikmod mime mjpegtools mmap mmx mng modplug moznocompose moznoirc moznomail mozxmlterm mp3 mpeg mplayer msn musepack mysql mysqli ncurses net netcdf network nfs nls nntp no-old-linux noamazon nocd nptl nptlonly nsplugin objc objc-gc odbc offensive ogg on-the-fly-crypt opengl oscar oss pam pam_chroot pam_console pam_timestamp pascal pcntl pcre pdf perl pg-hier pg-intdatetime pg-vacuumdelay png posix postgis postgres ppds proj pyste python qemu-fast qt qt4 quicktime quotas rar rdesktop readline real recode rle rss rtc samba sasl savedconfig sblive sdk sdl server session sftplogging sharedmem shorten sid simplexml skey slp sndfile soap sockets softmmu soundtouch speex spell sql sqlite sqlite3 sse sse2 ssl subversion svg svga sysfs tcl tcltk tcpd test tetex theora tiff toolbar truetype truetype-fonts type1-fonts unicode urandom usb utf8 vcd video_cards_vesa visualization vorbis win32codecs wma wmf x264 xanim xattr xcomposite xml xmlrpc xosd xpm xprint xsl xv xvid xvmc yahoo yv12 zeroconf zlib elibc_glibc input_devices_evdev kernel_linux linguas_en linguas_en_GB linguas_ja linguas_ko linguas_ru linguas_zh_CN linguas_zh_TW userland_GNU video_cards_i810 video_cards_i915 video_cards_fbdev video_cards_vga" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS
/me too
Quick update: ebuild /usr/portage/dev-lang/gnat-gcc-4.1.1.ebuild qmerge will complete the installation.
Yes, of course, but this is not even a workaround but rather a portage trickery. You could have also used FEATURES=-strict emerge ... A few words on this problem - this is a QA violation, but this is something that comes from upstream and which we need to seriously investigate and which is not critical for Ada. In fact executable stack is a common way to implement nested functions - which are absent in C standard but are very important in Ada. As such the fix involved is not going to be easy and, actually, I am personally not even sure how to approach this. A developer from hardened project (Kevin Quinn?) has promised to help, but well, this is a low priority for all of us as it is and thus is unlikely to be "fixed" soon. George
(In reply to comment #3) > As such the fix involved is not going to be easy and, actually, I am > personally not even sure how to approach this. A developer from hardened > project (Kevin Quinn?) has promised to help, but well, this is a low priority > for all of us as it is and thus is unlikely to be "fixed" soon. Yes; unfortunately I have too much other stuff that's higher priority. My aim was to eliminate the execstack requirement, but that's a big-ish job. You can add a "QA_EXECSTACK" definition to the ebuild, to prevent the FEATURES="stricter" check failing (for hardened use there's an override). Simply set it to a whitespace-separated list of files, relative to ${D}, that will fail. I'm pretty sure you can use wildcards, so: QA_EXECSTACK="usr/*/gnat-gcc-bin/4.1/gnatbind usr/*/gnat-gcc-bin/4.1/gnatmake usr/*/gnat-gcc-bin/4.1/gnatls usr/lib/gnat-gcc/*/4.1/adalib/libgnat-4.1.so usr/libexec/gnat-gcc/*/4.1/gnat1" should do the trick. The '*' matches the CTARGET, e.g. i686-pc-linux-gnu, which obviously changes depending on which arch you're building - although note that some arches may not need execstack. In detail, the problem for GNAT occurs when use is made of a GNAT extension (attribute Unrestricted_Access) which allows, amongst other things, nested subprograms to be called out of scope yet still access data from the scope of their declaration (rather than the scope of the call). gcc implements these with trampolines (small pieces of code generated at run-time on the stack), as it's pretty much the only way to do it for the permissive C language semantics without changing what a function pointer looks like (you'd have to change a subprogram pointer into a record of two pointers; one to the subprogram and one to the declaration scope). Normal Ada rules on scoping of subprogranm access types mean that they cannot be used in different scope to the subprogram - this means that the compiler always knows where the nested subprogram scope is with respect to the call, and so it's possible to deal with it without generating a trampoline. This explains how Ada works fine on embedded systems with non-executable RAM. However GNAT uses 'Unrestricted_Access to do exactly that - propogate subprogram pointers out of scope, in particular when it uses its Sort subprograms (which cannot be done the same way with standard Ada - the Ada way would be to have them as generics) - so you get trampolines and hence the execstack marking. It's dangerous, in that you could write silly code that would be meaningless; for example if you saved such a pointer then tried to access it later when it was no longer in any scope. See http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gnat_rm/Unrestricted_005fAccess.html#Unrestricted_005fAccess
gnat-gpl-3.4.6.2006 and gnat-gcc-4.1.x are marked with QA_EXECSTACK. Interestingly the gnat-gcc-4.2.0 that I just added to the tree did not trigger any execstack complaints. Lets hope there is no need to do so in future versions as well! I'll check/update the gnat-gcc-3.4 series and then close this bug. George
all gnat compilers were marked with QA_EXECSTACK. Closing.
