Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

I am unable to compile dev86 on an athlon XP 1500 using the hardened profile.
It
does compile on another athlon system I have (XP 1800). The only difference is
that the latter is running in vserver mode on top of debian.

This is a fresh system. I redid the scripts/bootstrap.sh and then 'emerge -e
world' to no avail.

I tested it with gcc-3.4.3 and gcc-3.3.6, same result.


Reproducible: Always
Steps to Reproduce:
1. Get an athlon XP system
2. Try to compile dev86

Actual Results:  
make -C elksemu elksemu
make[3]: Entering directory
`/var/tmp/portage/dev86-0.16.17/work/dev86-0.16.17/elksemu'
cc  -Wall -Wstrict-prototypes -O2 -g   -c -o elks.o elks.c
elks.c:36: warning: function declaration isn't a prototype
elks.c:139: warning: function declaration isn't a prototype
elks.c: In function `run_elks':
elks.c:132: error: can't find a register in class `BREG' while reloading `asm'
make[3]: *** [elks.o] Error 1
make[3]: Leaving directory
`/var/tmp/portage/dev86-0.16.17/work/dev86-0.16.17/elksemu'
make[2]: *** [elksemu] Error 2
make[2]: Leaving directory `/var/tmp/portage/dev86-0.16.17/work/dev86-0.16.17'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/var/tmp/portage/dev86-0.16.17/work/dev86-0.16.17'
make: *** [all] Error 2

Expected Results:  
dev 86 should compile cleanly.

Portage 2.0.53_rc7 (hardened/x86/2.6, gcc-3.4.4, glibc-2.3.5-r3,
2.6.13-hardened-r2 i686)
=================================================================
System uname: 2.6.13-hardened-r2 i686 AMD Athlon(tm) XP 1500+
Gentoo Base System version 1.12.0_pre9
dev-lang/python:     2.4.2
sys-apps/sandbox:    1.2.13
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-r1
sys-devel/binutils:  2.16.1
sys-devel/libtool:   1.5.20
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=athlon-xp -O3 -pipe -fforce-addr -fomit-frame-pointer
-funroll-loops -frerun-cse-after-loop -frerun-loop-opt -falign-functions=4
-mno-tls-direct-seg-refs"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config
/usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=athlon-xp -O3 -pipe -fforce-addr -fomit-frame-pointer
-funroll-loops -frerun-cse-after-loop -frerun-loop-opt -falign-functions=4
-mno-tls-direct-seg-refs"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig ccache digest distlocks fixpackages sandbox sfperms
strict"
GENTOO_MIRRORS="ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo
ftp://mirror.scarlet-internet.nl/pub/gentoo ftp://mirror.nutsmaas.nl/gentoo/
http://gentoo.mirror.intouch.nl/gentoo/"
MAKEOPTS="-j2"
PKGDIR="/usr/portage//packages/x86/"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage/"
SYNC="rsync://rsync.nl.gentoo.org/gentoo-portage"
USE="berkdb crypt curl dlloader hardened ncurses nls nptl pam perl pic python
readline ssl tcpd udev userlocales x86 zlib userland_GNU kernel_linux
elibc_glibc"
Unset:  ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY

Reopen if you are able to reproduce this with some sane C[XX]FLAGS, like
CFLAGS="-march=athlon-xp -O2 -pipe"

I redid the compile with 'sane' CFLAGS to no avail. Exactly the same error
shows up.

Portage 2.0.53_rc7 (hardened/x86/2.6, gcc-3.4.4, glibc-2.3.5-r3,
2.6.13-hardened-r2 i686)
=================================================================
System uname: 2.6.13-hardened-r2 i686 AMD Athlon(tm) XP 1500+
Gentoo Base System version 1.12.0_pre9
dev-lang/python:     2.4.2
sys-apps/sandbox:    1.2.13
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-r1
sys-devel/binutils:  2.16.1
sys-devel/libtool:   1.5.20
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=athlon-xp"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config
/usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=athlon-xp"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig digest distlocks fixpackages sandbox sfperms strict"
GENTOO_MIRRORS="ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo
ftp://mirror.scarlet-internet.nl/pub/gentoo ftp://mirror.nutsmaas.nl/gentoo/
http://gentoo.mirror.intouch.nl/gentoo/"
PKGDIR="/usr/portage//packages/x86/"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage/"
SYNC="rsync://rsync.nl.gentoo.org/gentoo-portage"
USE="berkdb crypt curl dlloader hardened ncurses nls nptl pam perl pic python
readline ssl tcpd udev userlocales x86 zlib userland_GNU kernel_linux
elibc_glibc"
Unset:  ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS,
PORTDIR_OVERLAY

I tried switching profiles to hardened and it compiled ok for me.

Compiler testcase from:
http://gcc.gnu.org/ml/gcc-prs/2002-07/msg00491.html

static int
cpuid (int id, int* p_eax, int* p_ebx, int* p_ecx, int* p_edx)
{
        __asm__ __volatile__ ("cpuid"
        : "=a" (*p_eax), "=b" (*p_ebx), "=c" (*p_ecx), "=d" (*p_edx)
        : "a" (id));
        return 1;
}

This should compile cleanly when using:
- gcc -c test.c
And might fail when compiling when using:
- gcc -c -fPIC test.c

In my case it fails in both cases:
test.c:4: error: can't find a register in class `BREG' while reloading `asm'

Seems to have something to do with Postition Independant Code . . .

Maybe related bug
http://smbugs.isurf.ca/show_bug.cgi?id=9528

About 'hardened compilers' and PIC
http://www.caddr.com/macho/archives/sbcl-devel/2004-11/4201.html
http://sources.redhat.com/ml/glibc-linux/2000-q2/msg00069.html

Other links
http://mail-index.netbsd.org/port-xen/2004/12/23/0002.html
http://mail-index.netbsd.org/port-xen/2004/12/22/0004.html
http://www.luga.at/mailing-lists/luga/2004/09/msg00055.html

It compiles fine on the same machine using a default-linux/2005.1 profile.

gcc test case fails, not a dev86 specific problem, reassigning.

no, bug in dev86

first off, the package ingores the users CFLAGS (even if they are riced to hell)

second, dev86 is failing to compile because it declares "b" as a clobbered
register which is wrong

Code in comment #4 clobbers ebx, which is why GCC complains when building
PIC; ebx is usually in use with PIC.  It'll fail without '-fPIC' on the
hardened compiler, which will switch on '-fPIE' when building code for
applications and amounts to the same thing here.

See the full PR at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7329

I think specifying 'b' as the operand is valid, and means the compiler
is instructed to choose an available register from the 'BREG' set (which
contains just bx & ebx), so it is valid, I think.

I'll post a fix shortly, as it's easy :)

i agree gcc should be intelligent about saving/restoring %ebx on its
own when inline asm declares it clobbered, but since gcc guys wont be
changing this behavior, our only solution is to 'fix' the broken code

Created an attachment (id=72058) [details]
Provide PIC alternative to inline asm

Patch can be applied unconditionally.  It uses the macro '__PIC__' to decide
which asm to build - this macro is set by GCC if it's building PIC for whatever
reason.

I've only checked it builds, and eyeballed the change.

it'd be better to just hide %ebx in say %ecx wouldnt it ?  since ecx
is a scratch register, gcc wont have to worry about restoring it if
no other code uses it ...

Like:

    __asm__ __volatile__(
        "movl %%ebx,%%ecx\n"
        "movl %2,%%ebx\n"
        "int $0x80\n"
        "movl %%ecx,%%ebx"
        :"=a" (__res):"a" ((int)OLD_SYS_vm86), "r" ((int)v86) : "ecx");

Assumes that 'int $0x80' (syscall) preserves %ecx.  I guess it does; using
push/pop just saves having to prove it :)

heh - of course it preserves ecx; otherwise all the syscalls would mark
everything as clobbered (and they don't!).  So yeah; stashing ebx in ecx would
be better as it may avoid slowere memory access.

Created an attachment (id=72080) [details]
ecx version of alternative PIC asm

here's the ecx version of the same patch.  Bit tidier as well.

(In reply to comment #14)
> heh - of course it preserves ecx; otherwise all the syscalls would mark
> everything as clobbered (and they don't!)

right, syscalls only clobber eax since that's the return register on x86 ...
otherwise we'd have a lot more problems as you said :)

Added patch and fixed cflags in -r2, thanks.

ps. I tried to report this upstream but got no reply from the author :-/