Bugzilla Bug 43440

l64seek.c: In function `_llseek':
l64seek.c:29: error: can't find a register in class `BREG' while reloading `asm'
make[1]: *** [l64seek.o] Error 1
make[1]: *** Waiting for unfinished jobs....
gpart.c:72: warning: built-in function `log' declared as non-function
make[1]: Leaving directory `/var/tmp/portage/gpart-0.1h/work/gpart-0.1h/src'
make: *** [gpart] Error 2


Yup, self explanatory.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

can you add CFLAGS="-static" and tell me what happens?

thanks,

Alex

still dies - here is my emerge info

Portage 2.0.50-r1 (hardened-x86-2004.0, gcc-3.3.2, glibc-2.3.2-r9, 2.6.1)
=================================================================
System uname: 2.6.1 i686 Unknown CPU Type
Gentoo Base System version 1.4.3.13
distcc 2.12.1 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled]
Autoconf: sys-devel/autoconf-2.58-r1
Automake: sys-devel/automake-1.7.7
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CFLAGS="-O2 -mcpu=athlon-xp -fomit-frame-pointer -funroll-loops -pipe"
CHOST="i686-pc-linux-gnu"
COMPILER="gcc3"
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/env.d"
CXXFLAGS="-O2 -mcpu=athlon-xp -fomit-frame-pointer -funroll-loops -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs ccache sandbox sfperms strict"
GENTOO_MIRRORS="http://gentoo.oregonstate.edu http://distro.ibiblio.org/pub/Linux/distributions/gentoo"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY=""
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="berkdb crypt pam pic readline ssl x86 zlib"

can you make the Makefile recognize the CFLAGS please and try again?

the mushrooms in my punkhead have emitted another funky idea:

gcc -static discards the -static flag when not linking
however, the hardened gcc exclude chain will recognize it and not build PIC

finally, the executable may contain text relocations because its not PIC

but, we build with -static so we force the use of statically linked executables which do not require TEXT relocations because they simply do not have any.

the reason is that in statically linked executables the locations of all relocations are fixed by the linker at link time of the different .o and .so

this -static fix if hardened is used WOUD save us a lot of work for all the bootloader and raidtools and pci utils business and so on.

it does not work for making libraries because those may be a bit pissed when built STATIC all the sudden

have a nice and bye from overworked Munich,

and thanks in advance,

Alex

Created an attachment (id=26797) [edit]
make.defs.diff

that patch fixes the prob. It adds '-static' to the CFLAGS in make.defs, which
is included in the Makefile. What next? add the patch to gpart and version
bump? Or send the patch upstream?

Re: comment #5

I think you would be able to add it without having to version bump if you did not want to. A -rX bump ~arch bump is the best way for to cover our own rears initially.

I dont think we sould have to push this upstream either. 
Outside of adamantix and hlfs and ourselves nobody else would probably really encounter this bug.

From looking at the code we might only have to add that patch only if we are using x86.

pappy, Do non x86 arches have problems with _syscall5() and BREG, ebx problems that your aware of?

This worked for me in the src_unpack()
use x86 &&
sed -i -e s/'-pedantic'/'-pedantic -static'/ make.defs

I mailed the base-system people for permission to add this in.

moving back to wranglers, release does not give me time to work on these

Is this still a problem?

yes, it is w/ sys-apps/gpart-0.1h

this fixes it for me, no textrelocs either in the end. as a sidenote, this
package ignores CFLAGS/LDFLAGS/etc, you may want to fix that as well.

--- l64seek.c.old   2004-08-20 00:46:10.000000000 +0200
+++ l64seek.c      2004-08-20 00:45:30.000000000 +0200
@@ -25,10 +25,6 @@
 } ostck[OSTACKLEN];
 static int             osptr = -1;

-#if defined(__linux__) && defined(__i386__)
-_syscall5(int,_llseek,uint,fd,ulong,hi,ulong,lo,loff_t *,res,uint,wh)
-#endif
-


 off64_t l64seek(int fd,off64_t offset,int whence)
@@ -41,7 +37,7 @@

        ohi = (unsigned long)((offset >> 32) & 0xFFFFFFFF);
        olo = (unsigned long)(offset & 0xFFFFFFFF);
-       iret = _llseek(fd,ohi,olo,&ret,whence);
+       iret = syscall(__NR__llseek, fd, ohi, olo, &ret, whence);
        if (iret == -1)
                ret = (off64_t)-1;
 #endif

should we send this patch upstream?

Yeah it's all yours now zhen.

Zhen, what is happening here, what can i do to get that thing out of sight?

Sinc.

Alex

well, sending the patch upstream was dumped in my lap. I am not a member of the
hardened herd, and consquently have absolutely no idea about this patch. I will
not send it upstream because I do not have the knowledge to support it. If the
hardened team wants to, please do, but I can't do it.

fixed in cvs ... _syscall#() on x86 hates PIC, so ive added a simple !
defined(__PIC__)

FI, ref. bug #79939 for root cause, standard kernel syscall headers vs PIC

This didn't build for me with latest PIC patch; I think the first #if
conditional in l64seek would also have to be adjusted.

Anyway; just tried it without the PIC patch, but with the latest 2.6.10 headers
and it seems ok.  Finds all the partitions on this machine, anyway.  Suggest
either removing the pic patch and making the ebuild DEPEND on 2.6.10 or
2.4.22-r1 linux-headers, or modifying the pic patch to fixup the second
conditional.