Emerging bogofilter-1.0.2 (or 1.0.3) with FEATURES=test and a hardened gcc (gcc-3.4.6-r2) results in a failed test: [...] ./outputs/bogolex.out ./checks.29608.20060810T120300/bogolex-batch.out differ: byte 5, line 1 FAIL: t.bulkmode [...] ====================== 1 of 44 tests failed Using the vanilla compiler or a nossp version makes the test succeed. Emerge --info: Gentoo Base System version 1.12.1 Portage 2.1-r2 (hardened/x86/2.6, gcc-hardenednopie, glibc-2.3.6-r4, 2.6.17 i686) ================================================================= System uname: 2.6.17 i686 AMD Athlon(tm) XP 2800+ app-admin/eselect-compiler: [Not Present] dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] 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=athlon-xp -Os -pipe -fomit-frame-pointer" 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/lib/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig collision-protect distlocks metadata-transfer notitles sandbox sfperms strict test userfetch userpriv usersandbox" LANG="en_GB.utf8" LINGUAS="en eo es nl" MAKEOPTS="-j1" PKGDIR="/usr/portage//packages/x86/" PORTAGE_RSYNC_EXTRA_OPTS="--progress --human-readable --exclude-from=/etc/portage/rsync_excludes" 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="/var/tmp" PORTDIR="/usr/portage/" PORTDIR_OVERLAY="/usr/local/portage" USE="3dnow X aac alsa apm arts asf audiofile avi bash-completion berkdb bzip2 cdparanoia cdr crypt dga dio dlloader dri dv encode exif fam fbcon ffmpeg flac gif glx gpm gtk gtk2 gtkhtml hardened imagemagick imap imlib jabber jpeg jpeg2k kde kdeenablefinal lcms lm_sensors mad mbox mbrola memlimit mikmod mime mmap mmx mng mp3 mpeg musepack nas ncurses nls nptl nsplugin ogg opengl oscar pdf pic png python qt3 quicktime readline recode sasl scanner sdl shorten sndfile sox speex spell sqlite sse ssl svg test theora threads tidy tiff truetype unicode usb userlocales vcd vorbis win32codecs wmf x86 xface xine xml xorg xpm xsl xv xvid zlib elibc_glibc input_devices_mouse input_devices_keyboard kernel_linux linguas_en linguas_eo linguas_es linguas_nl userland_GNU video_cards_via video_cards_vesa video_cards_fbdev" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS
Can someone from hardened have a look and/or give advice?
All passes fine here. Benno, can you attach the file ./checks.29608.20060810T120300/bogolex-batch.out from the working directory? (e.g. in /var/tmp/portage/bogofilter-1.0.2/work/bogofilter-1.0.2/src/tests)
Created attachment 95727 [details] everything in the output dir of the failing test, except the 320K wordlist.db After running 'SUPPRESS_DELETE=yes make check' in /var/tmp/portage/bogofilter-1.0.2/work/bogofilter-1.0.2/src/tests/ this is the content of bogolex-batch.out from checks.10746.20060902T141543: u 0.499414 u 0.500000 u 0.500000 u 0.500392 u 0.522257 u 0.501194 S 7.80e-05 S 9.57e-10
Ah; after quite some effort, I managed to reproduce the fault, and found the trigger. It's the '-Os' that triggers it - with '-O2' everything works fine. I suspect the real issue is that the tests that fail are expecting too much arithmetic accuracy from floating point operations, rather than -Os itself being incorrect. I've seen this sort of thing before (in glibc's tests, no less), where tests are written against a "golden executable", using the output of that as the data to be checked when the tests are run against a new build. One problem (there are several others ;) ) with this approach is that it does not take account of unexpected accuracy; for example if the compiler can calculate stuff itself, it will - and it will do so at full precision (whatever is most convenient for the compiler, provided the precision is as good or better than required), not at single-precision float for example. Variations in optimisation cause changes in how and where the compiler can pre-calculate constants like this; previously I've seen it triggered by PIE; but clearly this case shows it can happen with SSP in combination with -Os, as it is here. When such changes in compiler behaviour mean it actually generates code to do the calculation at run-time, the precision will be that of the types specified; i.e. single-precision float, with no "free" extra precision. My recommendation would be to avoid -Os and use -O2 on hardened systems; it's what we set in the hardened profile, mainly because it's the optimisation level that is most commonly used. -Os is a bit specialised - it focuses on code size and sacrifices code speed (e.g. it skips the various alignment optimisations, causing a speed impact on the memory subsystem). Unless you really do have an issue with the size of executables, stick with -O2. Above -O2, the optimisations all start to be specialised, in that they are a benefit in some situations, but a drawback in others (that's why they're not in '-O2'). See 'info gcc' section 3.10 for details. (-fomit-frame-pointer is fine, btw - it helps with PIE building, but sacrifices some debug-ability which is not something that is a common concern on production hardened systems) Tove: as far as bogofilter is concerned, if you want to do anything at all then you could issue an 'ewarn' in the src_test phase conditional on 'gcc-specs-ssp' (from toolchain-funcs.eclass) and having -Os in CFLAGS, but I don't think it's worth it. If anyone else trips it, they should find this bug (I've beefed up the summary to help trigger searches).
Thanks for the thorough explanation and advice, Kevin, it's much appreciated. Indeed, with -O2 the wayward test passes; I should have found this myself. Soon I'll recompile the whole system with -O2.
Kevin, thank you very much for your investigation and explanation. I am not adding a warning to src_test for now.
