dosbox-0.62 and dosbox-0.61 don't compile with gcc-3.4.2-r1 hardened. However, compiling with gcc-3.3.4-r1 unhardened works fine. Based on the fact that gcc is reporting an error in the PIC register, I suspect the problem is with the hardened part rather than the gcc-3.4 part. Reproducible: Always Steps to Reproduce: 1. gcc-config i686-pc-linux-gnu-3.4.2 2. emerge dosbox 3. see error Actual Results: For 0.62: g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../include -I/usr/include/SDL -D_REENTRANT -march=athlon-xp -O2 -pipe -frename-registers -fomit-frame-pointer -c -o core_dyn_x86.o `test -f 'core_dyn_x86.cpp' || echo './'`core_dyn_x86.cpp core_dyn_x86/risc_x86.h: In function `Bits CPU_Core_Dyn_X86_Run()': core_dyn_x86/risc_x86.h:128: error: PIC register `%ebx' clobbered in `asm' make[4]: *** [core_dyn_x86.o] Error 1 For 0.61: g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../include -march=athlon-xp -O2 -pipe -frename-registers -fomit-frame-pointer -I/usr/include/SDL -D_REENTRANT -c -o core_dyn_x86.o `test -f 'core_dyn_x86.cpp' || echo './'`core_dyn_x86.cpp In file included from core_dyn_x86.cpp:33: ../../include/paging.h:91: warning: `packed' attribute ignored In file included from core_dyn_x86.cpp:143: core_dyn_x86/cache.h:302:2: warning: no newline at end of file core_dyn_x86/risc_x86.h: In function `Bits CPU_Core_Dyn_X86_Run()': core_dyn_x86/risc_x86.h:133: error: PIC register `%ebx' clobbered in `asm' make[4]: *** [core_dyn_x86.o] Error 1 Expected Results: emerged successfully Portage 2.0.51_rc7 (default-x86-1.4, gcc-3.4.2, glibc-2.3.3.20040420-r1, 2.6.8-gentoo i686) ================================================================= System uname: 2.6.8-gentoo i686 AMD Athlon(tm) XP 2500+ Gentoo Base System version 1.4.16 distcc 2.17 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled]Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.14.90.0.8-r1 Headers: sys-kernel/linux26-headers-2.6.8.1 Libtools: sys-devel/libtool-1.5.2-r5 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -O2 -pipe -frename-registers -fomit-frame-pointer " CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.3/share/config:/usr/kde/3.3/env:/usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /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/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -O2 -pipe -frename-registers -fomit-frame-pointer " DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache distlocks sandbox" GENTOO_MIRRORS="http://gentoo.osuosl.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="3dnow X aac aalib acpi aim alsa apm arts avi berkdb bitmap-fonts bonobo cdr cjk cmucl crypt cups curl dga dnd doc dumb-allegro dvd dvdr editor emacs encode erandom esd ethereal evo faad fbcon ffmpeg fftw flac flash foomaticdb gdbm gif gnome gphoto2 gpm gtk gtk2 gtkhtml guile hardened imlib jack java jce jpeg kde ldap libg++ libwww mad mbox mikmod mmx mng motif mozdevelop mozilla moznocompose moznoirc moznomail mozsvg mozxmlterm mpeg mule mysql nas ncurses nls nptl oav odbc oggvorbis opengl opie oss pam pcre pda pdflib perl pic plotutils png postgres python qt quicktime readline samba scanner sdl slang slp spell sse ssl svg tcltk tcpd tetex tiff truetype unicode usb wmf x86 xface xinerama xml2 xmms xprint xv xvid zlib"
Re: "I suspect the problem is with the hardened part rather than the gcc-3.4 part." Actually the problem here is that dosbox-0.62 and most any program in the tree that starts with dos* is simply not pic aware. Considering that it's in games-emulation chances are the hardened team is not going to devote resources into making it pic/pie aware. Try CFLAGS="-nopie" emerge dosbox --nodeps
You are right. CFLAGS="-nopie" still doesn't work, but CXXFLAGS="-nopie" compiles and works properly.
What's the hardened team's recommendation in this case?
It's not setXid so the risk factor is pretty low. -rwxr-x--- 1 root games 993444 Sep 30 22:42 /usr/games/bin/dosbox The offending block of code is some inline asm which would also be riddled with text relocations. Basically it's not worth our time. If we had to recommend anything it would be. 1) don't use dosbox. 2) edit the ebuild to allow this to compile for other people. The logic would be something like so. inherit flag-o-matic src_unpack() { filter-flags -fPIC } If that does not work then try append-flags -fno-pic or use hardened && append-flags -nopie Lots of ways to work around this. But sorry no inline __asm__ love for you. Alternatively the user could/should also get in contact with the upstream maintainer/author of dosbox and explain the problem at hand and work with them on a proper long term solution. #if defined(__PIC__) || defined(__pic__) // New block of ams that's pic aware here. Or raw c #else // Orig inline asm that's not pic aware here. #endif
Alex - Can you try adding flag-o-matic to the inherit line and filter-flags -fPIC to the src_unpack function please? If that works, I'll add it to the ebuild in portage.
The dosbox guys suggested that passing --disable-dynamic-x86 might make it work. Can you give that a try and report please?
Adding --disable-dynamic-x86 to ./configure in the ebuild works for me, dosbox-0.62 emerges without problems then. But please note, that I just checked, if it compiles, not if dosbox behaves correctly after emerging it. ;-)
Have you had a chance to try running anything under dosbox with --disable-dynamic-x86 passed to configure? I'll go ahead and pass that in the case of USE="hardened" if it seems to work ok.
I am using dosbox only occasionally and right now I have no spare time for these old DOS games. ;-) But I will try to test a little bit when I return home this evening. Mhmm, I just remembered, that my machine at home still uses gcc-3.3.4 and that I can't test with gcc-3.4.2 at the moment. But the error described in this bug occurs with gcc-3.3.4 too, therefore I would expect that --disable-dynamic-x86 will also work for gcc-3.4.2 if it works for gcc-3.3.4.
Ok. I added a patch to the ebuild. If that doesn't make things happy, I can try other things.
Sorry for the delay... :-( OK, I reemerged dosbox-0.62 and it compiled and worked. I could start some of my old DOS games. I am not sure, if there was any performance impact as that is a highly subjective matter without proper measurements... At the moment I would conclude, that everything is OK. Of course, it would be desirable that the dosbox developers fix this dynamic x86 core in the near future. ;-)
yeah....that's probably not going to happen. If it works at all with hardened, that's probably the best we can hope for. Thanks for testing.
