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 attachment 26797 [details, diff] 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.
