Bugzilla Bug 75789

Emerging valgrind-2.2.0 with enabled maketest FEATURE results in a fatal error
during test phase:

make[4]: Entering directory
`/var/tmp/portage/valgrind-2.2.0/work/valgrind-2.2.0/tests'
if gcc -DHAVE_CONFIG_H -I. -I. -I..     -Winline -Wall -Wshadow -g  -MT
cputest.o -MD -MP -MF ".deps/cputest.Tpo" -c -o cputest.o cputest.c;\
then mv -f ".deps/cputest.Tpo" ".deps/cputest.Po"; else rm -f
".deps/cputest.Tpo"; exit 1; fi
cputest.c: In function `cpuid':
cputest.c:9: error: can't find a register in class `BREG' while reloading `asm'
make[4]: *** [cputest.o] Error 1
make[4]: Leaving directory
`/var/tmp/portage/valgrind-2.2.0/work/valgrind-2.2.0/tests'
make[3]: *** [check-am] Error 2
make[3]: Leaving directory
`/var/tmp/portage/valgrind-2.2.0/work/valgrind-2.2.0/tests'
make[2]: *** [check-recursive] Error 1
make[2]: Leaving directory
`/var/tmp/portage/valgrind-2.2.0/work/valgrind-2.2.0/tests'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory
`/var/tmp/portage/valgrind-2.2.0/work/valgrind-2.2.0'
make: *** [check] Error 2

I think this issue only shows up with the hardened toolchain, "make check"
works properly on a non-hardened system using the same gcc version.
Unfortunately the ebuild does not honor the appropriate CFLAGS for disabling
PIE/SSP in gcc.

Reproducible: Always
Steps to Reproduce:
1.add "maketest" to FEATURES
2.emerge \=dev-util/valgrind-2.2.0 (while using a hardened gcc)




# emerge info
Portage 2.0.51-r3 (hardened/x86/2.6, gcc-3.3.4, glibc-2.3.4.20040808-r1,
2.6.7-hardened-r15 i686)
=================================================================
System uname: 2.6.7-hardened-r15 i686 Pentium III (Coppermine)
Gentoo Base System version 1.4.16
distcc 2.16 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632)
[disabled]
Autoconf: sys-devel/autoconf-2.59-r5
Automake: sys-devel/automake-1.8.5-r1
Binutils: sys-devel/binutils-2.15.90.0.1.1-r3
Headers:  sys-kernel/linux26-headers-2.6.8.1-r1
Libtools: sys-devel/libtool-1.5.2-r7
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CFLAGS="-nopie"
CHOST="i686-pc-linux-gnu"
COMPILER=""
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config
/usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown
/usr/kde/3/share/config /usr/lib/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/ /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-nopie"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig ccache distlocks maketest sandbox strict"
GENTOO_MIRRORS="http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/
ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/"
MAKEOPTS="-j4"
PKGDIR="/usr/portage//packages/x86/"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage/"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://linux.rz.ruhr-uni-bochum.de/gentoo-portage"
USE="X X509 aalib acpi acpi4linux alsa ared aredmem arts berkdb bootspla bzlib
c
crypt css cups dga directfb divx4linux dlloader dvd fam flac foomaticdb gd gdbm
gif gnuplot gs gsl gtk hardened imap imlib imlib2 innodb ipv6 java kde libwww
lzo mbox md5sum mha mikmod mime mmx mmx2 mng mozilla mozinterfaceinfo mozsvg
mplayer ncurses network nls no_wxgtk1 nptl ntlm oggvorbis opengl pam pcmcia
pcre
pdflib perl pic pie plotutils png pnp ppds python qt readline real rtc samba
sasl sdl sftplogging slang smime sockets speex sse ssl tcpd tetex theora tidy
tiff truetype-fonts type1 type1-fonts usb webmin-minimal x86 xine xml2 xmms
xvid
zlib"

Created an attachment (id=49731) [edit]
Allows test feature to build; fixes non-pic-aware cpuid code

Another cpuid occurrence; ebx must be preserved across the call.
Also, "filter-flags -fPIC" is in the ebuild; I think this can be removed (seems
to work ok here with it removed).

Hmm, that's odd, cpuid is not the only part of the tests clobbering ebx. 
Can you double check you are using hardened gcc and have maketest in your features?

I've been talking with the upstream developers and we are trying to fix this
issue. Hopefully they will change valgrind's makefiles to respect CFLAGS in the 
environment so the filter-flags -fPIC actually has any effect.

Created an attachment (id=49788) [edit]
emerge log

Well, I've checked and gcc was definitely hardened, and maketest is in
FEATURES.  In fact I've just done it again to be sure.

What may be happening, is that the tests are being built, but perhaps are not
actually being run?

I've attached the emerge log.

Could you attach the file insn_basic.c that is created during make check?

Created an attachment (id=49832) [edit]
insn_basic.c generated during make test

Created an attachment (id=49840) [edit]
Assembler, generated from the same compilation command used to generate
insn_basic.o but with '-o insn_basic.o' replaced with '-S'

Curious.  It seems there are places where ebx is trashed, but the compiler
hasn't noticed - perhaps I'm misunderstanding something. See around line 3070
of the attached disassembly (function adcb_3); looks to me like the #APP/NO_APP
section trashes bl, and there by ebx, yet the subsequent instructions happily
do 'leal .LC103@GOTOFF(%ebx), %eax' which relies on the previously setup ebx.

Attachement compressed as bugzilla refused the uncompressed file.

What's your gcc --version output?

$ gcc --version
gcc (GCC) 3.3.5  (Gentoo Hardened Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I'm using 3.4.3-r1, so that's probably it. If you feel like it you could try 
out 3.4.3 yourself, but I don't mind if you don't.

I already had 3.4.3-r1 installed for testing, so tried it out - yes that was
it; got a ream of clobbers with 3.4.3-r1 in insn_basic.c.

Bit worrying that 3.3.5-r1 generates broken code like that; assuming I'm
reading the 3.3.5-r1 assembler output right.  Looks like 3.3.5 doesn't
recognise that bl clobbers ebx!

I asked upstream to fix this by respecting the CFLAGS environment variable so
the 
ebuild would be able to disable pie. Unfortunately they have not responded yet, 
so I'll go ahead and check in 2.2.0-r2 which includes this fix.

It is possible that this introduces problems with other CFLAGS that did not pop 
up until now, but I'll deal with those when I get to hear about them.

It works for me now, if you experience any further problems please reopen this
one.

leal means load effective address low and is used by PIC code to determine the
location of data while doing GOT relative addressing.

it sure is alright to clobber ebl (ebx lower 16 bit part) if leal is restoring
the ebl to the correct offset of the data to be retrieved via PIC addressing
through GOT relative.

correct me if i'm wrong, but that's the reason it works afaik.


Alex

Code segment is:

    .loc 1 1168 0
#APP
    fsave -152(%ebp)
movb -153(%ebp), %bl        <-- load %bl with -154(%ebp) (clobber %ebx)
pushfl
andl $0xfffffffe, (%esp)
orl $0x00000000, (%esp)
popfl
adcb $12, %bl               <-- add 0x12 to it
movb %bl, -154(%ebp)        <-- store result in -154(%ebp)
frstor -152(%ebp)           <-- note - doesn't restore ebx

    .loc 1 1183 0
#NO_APP
    cmpb    $46, -154(%ebp)
    jne .L153
    .loc 1 1185 0
    leal    .LC103@GOTOFF(%ebx), %eax

so that the leal instruction doesn't get what it should do in %ebx.
This was a problem in gcc-3.3.5, because it didn't realise that bl was part of
the PIC register in all cases.  gcc-3.4.6-r1 picks this up properly:

insn_basic.c: In function `adcb_3':
insn_basic.c:1168: error: PIC register `bl' clobbered in `asm'