I tried to update sparc chroot up to unstable state and got glibc failure. Tried latest sparc gcc:4.3, gcc:4.4 and ~sparc gcc:4.3, gcc:4.4. The sippet of failure (reproducible if I change the directory and try to rerun it): CPP='sparc-unknown-linux-gnu-gcc -E -x c-header' /var/tmp/portage/sys-libs/glibc-2.12.1-r1/work/build-sparc32-sparc-unknown-linux-gnu-nptl/elf/ld-linux.so.2 --library-path /var/tmp/portage/sys-libs/glibc-2.12.1-r1/work/build-sparc32-sparc-unknown-linux-gnu-nptl:/var/tmp/portage/sys-libs/glibc-2.12.1-r1/work/build-sparc32-sparc-unknown-linux-gnu-nptl/math:/var/tmp/portage/sys-libs/glibc-2.12.1-r1/work/build-sparc32-sparc-unknown-linux-gnu-nptl/elf:/var/tmp/portage/sys-libs/glibc-2.12.1-r1/work/build-sparc32-sparc-unknown-linux-gnu-nptl/dlfcn:/var/tmp/portage/sys-libs/glibc-2.12.1-r1/work/build-sparc32-sparc-unknown-linux-gnu-nptl/nss:/var/tmp/portage/sys-libs/glibc-2.12.1-r1/work/build-sparc32-sparc-unknown-linux-gnu-nptl/nis:/var/tmp/portage/sys-libs/glibc-2.12.1-r1/work/build-sparc32-sparc-unknown-linux-gnu-nptl/rt:/var/tmp/portage/sys-libs/glibc-2.12.1-r1/work/build-sparc32-sparc-unknown-linux-gnu-nptl/resolv:/var/tmp/portage/sys-libs/glibc-2.12.1-r1/work/build-sparc32-sparc-unknown-linux-gnu-nptl/crypt:/var/tmp/portage/sys-libs/glibc-2.12.1-r1/work/build-sparc32-sparc-unknown-linux-gnu-nptl/nptl /var/tmp/portage/sys-libs/glibc-2.12.1-r1/work/build-sparc32-sparc-unknown-linux-gnu-nptl/sunrpc/rpcgen -Y ../scripts -h rpcsvc/key_prot.x -o /var/tmp/portage/sys-libs/glibc-2.12.1-r1/work/build-sparc32-sparc-unknown-linux-gnu-nptl/sunrpc/rpcsvc/key_prot.T make[2]: *** [/var/tmp/portage/sys-libs/glibc-2.12.1-r1/work/build-sparc32-sparc-unknown-linux-gnu-nptl/sunrpc/rpcsvc/key_prot.stmp] Segmentation fault (core dumped) I tried to change '/var/tmp/portage/sys-libs/glibc-2.12.1-r1/work/build-sparc32-sparc-unknown-linux-gnu-nptl/elf/ld-linux.so.2' to '/lib/ld-linux.so.2' with no change. Same SIGSEGV. So I think 'rpcgen' bits are slightly broken. -ggdb3 Backtrace for rpcgen (may be inaccurate, as I'm not sure gdb loaded proper symbols for libc): #0 0xf857d210 in ?? () #1 0x00017538 in def_union () at rpc_parse.c:369 #2 get_definition () at rpc_parse.c:76 #3 0x00012600 in h_output (infile=<value optimized out>, extend=0, outfile=<value optimized out>, define=<value optimized out>) at rpc_main.c:592 #4 0x00013b7c in main (argc=7, argv=0xffffcf24) at rpc_main.c:202 (gdb) bt #0 0xf857d210 in ?? () #1 0x00017538 in def_union () at rpc_parse.c:369 #2 get_definition () at rpc_parse.c:76 #3 0x00012600 in h_output (infile=<value optimized out>, extend=0, outfile=<value optimized out>, define=<value optimized out>) at rpc_main.c:592 #4 0x00013b7c in main (argc=7, argv=0xffffcf24) at rpc_main.c:202 Whole 'emerge --info' and build.log will follow.
Created attachment 246810 [details] emerge --info
Build log for CFLAGS="-O1 -ggdb3 -mcpu=ultrasparc -pipe" USE=debug emerge -av1 glibc (-O1 -ggdb3 does not seem to matter, without them build fails in the same place. And -O1 was practically ignored) http://dev.gentoo.org/~slyfox/bugs/336792/build.log (13MB!) http://dev.gentoo.org/~slyfox/bugs/336792/build.log.bz2 (140KB)
bt full: (gdb) frame 1 #1 0x00017538 in def_union () at rpc_parse.c:369 369 *defp->def.un.default_decl = dec; (gdb) bt full #0 0xf84cd210 in ?? () No symbol table info available. #1 0x00017538 in def_union () at rpc_parse.c:369 tok = {kind = TOK_COLON, str = 0x1fca8 "default"} dec = {prefix = 0x0, type = 0x1f080 "void", name = 0x70036a10 "deskey", rel = REL_ALIAS, array_max = 0xffdd4c58 "\377\335M", <incomplete sequence \310>} cases = 0x700369d8 tailp = 0x700369f4 #2 get_definition () at rpc_parse.c:76 defp = 0x70036970 tok = {kind = TOK_UNION, str = 0x1fbb0 "union"} #3 0x00012600 in h_output (infile=<value optimized out>, extend=0, outfile=<value optimized out>, define=<value optimized out>) at rpc_main.c:592 xdrfuncp = <value optimized out> tell = 193 guard = 0x70036300 "KEY_PROT_H_RPCGEN" l = <value optimized out> #4 0x00013b7c in main (argc=7, argv=0xffdd4ed4) at rpc_main.c:202 cmd = {cflag = 0, hflag = 1, lflag = 0, mflag = 0, nflag = 0, sflag = 0, tflag = 0, Ssflag = 0, Scflag = 0, makefileflag = 0, infile = 0xffdd54b5 "rpcsvc/key_prot.x", outfile = 0xffdd54ca "/var/tmp/portage/sys-libs/glibc-2.12.1-r1/work/build-sparc32-sparc-unknown-linux-gnu-nptl/sunrpc/rpcsvc/key_prot.T"}
do not post links to logs. all logs go in the bug as attachments. does USE=-sandbox make a difference ?
> do not post links to logs. all logs go in the bug as attachments. Should I reattach them for hiastory? If yes then compressed of uncompressed? (I'm afraid my internets won't allow me to attach 13MB file) > does USE=-sandbox make a difference ? I rerun 'rpcgen' directly from source tree without sandbox and getting coredump. Should I try to rebuild whole tree with USE=-sandbox? Looking at backtrace it seems the rpc stubfile parser is broken.
bugzilla wont take large files. so you will have to attach the compressed log. if rpcgen is failing by hand, then you probably dont need to rebuild everything with FEATURES=-sandbox.
Created attachment 246891 [details] the log from comment #2. nothing new
Currently I'm playing with SIGSEGV by running glibc-2.12.1 $ CFLAGS="-ggdb3 -O0" make -r subdir=sunrpc objdir=$(pwd)/../build-sparc32-sparc-unknown-linux-gnu-nptl/ -C sunrpc ..=../ others It takes some seconds to see the crash. core dump is about 2.2GBs (which might be sparc specific stack pollution or memory allocator breakage)
I straced rpcgen and noticed brk() calls return very unusual addresses: 'strace new-ld new-rpcgen': 18057 brk(0) = 0x70036000 18057 brk(0x70058000) = 0x70058000 <fault at address around 0x70036720> 'strace old-ld new-rpcgen': 3371 brk(0) = 0x36000 3371 brk(0x58000) = 0x58000 <works as expected> So seems glibc-2.12.1 loader fools brk() somehow
> 18057 brk(0x70058000) = 0x70058000 It's a ld.so's lower bound. Is it valid to give a program address there? > 3371 brk(0x58000) = 0x58000 It's application's lower bound address space. It can be traced by trapping on 'brk' function in built glibc. I see bug #293632 fails in similar place. Could it be the bug linux kernel in handling 32bit-userstace-to-64-bit-kernel-space and back?
I've marked it -sparc meanwhile
(In reply to comment #10) > > 18057 brk(0x70058000) = 0x70058000 > It's a ld.so's lower bound. Is it valid to give a program address there? > > > 3371 brk(0x58000) = 0x58000 > It's application's lower bound address space. I messed thing up. I compared raw rpcgen run and via-ld case. They obviosly have differend base brk() addresses (as ld.so, as binary adjust lower code bound address). So they are incorrect. Fault occurs here atrpc_parse.c:369: 370 *new_dec = dec; 0x000173ac <+2092>: mov %l4, %o1 0x000173b0 <+2096>: mov %l1, %o0 0x000173b4 <+2100>: call 0x3413c <memcpy@plt> 0x000173b8 <+2104>: mov 0x14, %o2 My next theory is glibc got broken memcpy somewhere around: commit dbcaf07c326e18b14d19aebe011b9ffbe4a45972 Author: David S. Miller <davem@davemloft.net> Date: Sun Feb 21 20:12:29 2010 -0800 sparc: Reimplement 64-bit aligned copy routines and remove from memcpy files.
Whole testcase to verify the problem: bender sunrpc # cat mem_test.c #include <string.h> int main() { #define SZ 0x24 char * dst = malloc (SZ); char src[SZ] = { '!' }; memcpy (dst, src, SZ); return 0; } bender sunrpc # gcc -O2 -ggdb3 mem_test.c -o mt bender sunrpc # cat > /dev/null # got from objdump 000104c0 <main>: 104c0: 9d e3 bf 78 save %sp, -136, %sp 104c4: 40 00 46 e8 call 22064 <malloc@plt> 104c8: 90 10 20 24 mov 0x24, %o0 104cc: 82 10 20 21 mov 0x21, %g1 104d0: c0 27 bf d8 clr [ %fp + -40 ] 104d4: c0 27 bf dc clr [ %fp + -36 ] 104d8: c0 27 bf e0 clr [ %fp + -32 ] 104dc: c0 27 bf e4 clr [ %fp + -28 ] 104e0: c0 27 bf e8 clr [ %fp + -24 ] 104e4: c0 27 bf ec clr [ %fp + -20 ] 104e8: c0 27 bf f0 clr [ %fp + -16 ] 104ec: c0 27 bf f4 clr [ %fp + -12 ] 104f0: c0 27 bf f8 clr [ %fp + -8 ] 104f4: c2 2f bf d8 stb %g1, [ %fp + -40 ] 104f8: 92 07 bf d8 add %fp, -40, %o1 104fc: 94 10 20 24 mov 0x24, %o2 10500: 40 00 46 d6 call 22058 <memcpy@plt> 10504: b0 10 20 00 clr %i0 10508: 81 c7 e0 08 ret bender sunrpc # /var/tmp/portage/sys-libs/glibc-2.12.1-r1/work/build-sparc32-sparc-unknown-linux-gnu-nptl/elf/ld-linux.so.2 --library-path /var/tmp/portage/sys-libs/glibc-2.12.1-r1/work/build-sparc32-sparc-unknown-linux-gnu-nptl:/var/tmp/portage/sys-libs/glibc-2.12.1-r1/work/build-sparc32-sparc-unknown-linux-gnu-nptl/math:/var/tmp/portage/sys-libs/glibc-2.12.1-r1/work/build-sparc32-sparc-unknown-linux-gnu-nptl/elf:/var/tmp/portage/sys-libs/glibc-2.12.1-r1/work/build-sparc32-sparc-unknown-linux-gnu-nptl/dlfcn:/var/tmp/portage/sys-libs/glibc-2.12.1-r1/work/build-sparc32-sparc-unknown-linux-gnu-nptl/nss:/var/tmp/portage/sys-libs/glibc-2.12.1-r1/work/build-sparc32-sparc-unknown-linux-gnu-nptl/nis:/var/tmp/portage/sys-libs/glibc-2.12.1-r1/work/build-sparc32-sparc-unknown-linux-gnu-nptl/rt:/var/tmp/portage/sys-libs/glibc-2.12.1-r1/work/build-sparc32-sparc-unknown-linux-gnu-nptl/resolv:/var/tmp/portage/sys-libs/glibc-2.12.1-r1/work/build-sparc32-sparc-unknown-linux-gnu-nptl/crypt:/var/tmp/portage/sys-libs/glibc-2.12.1-r1/work/build-sparc32-sparc-unknown-linux-gnu-nptl/nptl ./mt Segmentation fault
nice test case if you link statically, do you get same behavior ?
> if you link statically, do you get same behavior ? I don't know how to build it having halfbuild libc sources. Tried such trick: bender sunrpc # gcc -O2 -ggdb3 mem_test.c -nodefaultlibs -nostdlib -static -L../../build-sparc32-sparc-unknown-linux-gnu-nptl/ -lc -L/usr/lib/gcc/sparc-unknown-linux-gnu/4.4.4/ -lgcc -o mt failed with many unresolved symbols: bender sunrpc # gcc -O2 -ggdb3 mem_test.c -nodefaultlibs -nostdlib -static -L../../build-sparc32-sparc-unknown-linux-gnu-nptl/ -lc -L/usr/lib/gcc/sparc-unknown-linux-gnu/4.4.4/ -lgcc -o mt /usr/lib/gcc/sparc-unknown-linux-gnu/4.4.4/../../../../sparc-unknown-linux-gnu/bin/ld: warning: cannot find entry symbol _start ; defaulting to 0000000000010200 ../../build-sparc32-sparc-unknown-linux-gnu-nptl//libc.a(iofflush.o): In function `_IO_acquire_lock_fct': /var/tmp/portage/sys-libs/glibc-2.12.1-r1/work/glibc-2.12.1/libio/libioP.h:969: undefined reference to `_Unwind_Resume' ../../build-sparc32-sparc-unknown-linux-gnu-nptl//libc.a(iofflush.o):(.eh_frame+0x13): undefined reference to `__gcc_personalit y_v0' ../../build-sparc32-sparc-unknown-linux-gnu-nptl//libc.a(iofputs.o): In function `_IO_acquire_lock_fct': /var/tmp/portage/sys-libs/glibc-2.12.1-r1/work/glibc-2.12.1/libio/libioP.h:969: undefined reference to `_Unwind_Resume' ../../build-sparc32-sparc-unknown-linux-gnu-nptl//libc.a(iofputs.o):(.eh_frame+0x13): undefined reference to `__gcc_personality _v0' Seems I need something lowlevel, like gcrt1.o and other bits. Should I explicitely mention all binaries containig missing symbols or there is simpler way?
dont use -nostdlib and -nostartfiles. use -B when specifying the local C library paths, not -L.
> dont use -nostdlib and -nostartfiles. use -B when specifying the local C > library paths, not -L. This one did the trick: build-sparc32-sparc-unknown-linux-gnu-nptl # gcc -O2 -ggdb3 mem_test.c -o mem_test -v -Wl,--verbose -B$(pwd) -static It linked against local libc.a and system's startfiles (which might be not very good): /usr/lib/gcc/sparc-unknown-linux-gnu/4.4.4/../../../crt1.o /usr/lib/gcc/sparc-unknown-linux-gnu/4.4.4/../../../crti.o /usr/lib/gcc/sparc-unknown-linux-gnu/4.4.4/crtend.o /usr/lib/gcc/sparc-unknown-linux-gnu/4.4.4/../../../crtn.o The binary stopped crashing so i slightly changed testcase: #include <string.h> #include <stdio.h> int main() { #define SZ 0x24 char * dst = malloc (SZ); char src[SZ] = "hello! how are you?"; memcpy (dst, src, SZ); printf ("dst:%s\n", dst); return 0; } # c - current, n - new (local) # gcc -O2 -ggdb3 mem_test.c -o mem_test.clibc -static # gcc -O2 -ggdb3 mem_test.c -o mem_test.nlibc -B$(pwd) -static bender build-sparc32-sparc-unknown-linux-gnu-nptl # ./mem_test.clibc dst:hello! how are you? bender build-sparc32-sparc-unknown-linux-gnu-nptl # ./mem_test.nlibc dst: I tried to trace it with gdb and seems 'memcpy' dispatcher does not call any of __memcpy_* backend functions.
I preinitialized dst with raw memory writes and made sure memcpy does not modify dst. #include <string.h> #include <stdio.h> int main() { #define SZ 0x24 char * dst = malloc (SZ); char ini[SZ] = "initial value"; typedef unsigned int u32; unsigned i; /* aligned writes, not very precise tailwise */ for (i = 0; i < strlen (ini); i += sizeof (u32)) *(u32*)(dst + i) = *(u32*)(ini + i); *(u32*)(dst + i) = 0; char src[SZ] = "hello! how are you?"; memcpy (dst, src, SZ); printf ("dst:%s\n", dst); return 0; } #### the same -static case: # ./mem_test.clibc dst:hello! how are you? # ./mem_test.nlibc dst:initial value So it seems to fallthru all implementations in -static case: http://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/sparc/sparc64/multiarch/memcpy.S;h=a708de10e22d505fb015044129fb9cc701d4aec1;hb=6164128f1ca84eea240b66f977054e16b94b3c86
Could it be 'gnu_indirect_function' does not work on sparc? What part of libc/gcc is supposed to handle return value from such functions? According to gdb it returns back to program (as normal function).
http://vger.kernel.org/~davem/cgi-bin/blog.cgi/2010/02/07
(In reply to comment #20) > http://vger.kernel.org/~davem/cgi-bin/blog.cgi/2010/02/07 > In particular we don't have exactly this patch in binutils: http://sourceware.org/ml/binutils/2010-02/msg00095.html
On my conclusion > > My distro just does not ship binutils with STT_GNU_IFUNC patch yet. davem answered: > GLIBC should build properly, and work just fine, even if your binutils > lacks STT_GNU_IFUNC support. /me completely confused
try configuring glibc with --disable-multi-arch
(In reply to comment #23) > try configuring glibc with --disable-multi-arch > Tried such cmdline: EXTRA_ECONF="--disable-multi-arch" FEATURES="test -stricter -strict" ebuild /bound/portage/sys-libs/glibc/glibc-2.12.1-r1.ebuild clean unpack install And miracle happened: glibc has built successfully (and ran the tests) As I understand we have a bug (or unimplemented feature) AND/OR: * glibc should detect lack of indirect functions support on binutils side * binutils should fail when tries to compile code declaring indirect functions (I expected failure like this: bug #333545)
there are two parts to binutils. the common front ends which recognize the gnu_indirect_function type and the target specific back ends which take care of handling that code. at the moment, only the front end is checked and thus everyone is detected as supporting gnu_indirect_function. whether this is expected behavior, i do not know. i'll follow up on the binutils mailing list.
i built it up to double check, and glibc is def not doing the right thing: $ readelf -s libc.so.6 | grep '\<memcpy\>' 1248: 0008e600 136 IFUNC GLOBAL DEFAULT 10 memcpy@@GLIBC_2.0 which means that David is mistaken that glibc builds & works with a binutils that lacks *sparc* support for indirect functions. glibc will probably need its configure test extended, but i really have no idea how to do that other than creating a white list of arch/binutils versions where indirection functions are known to work front & back.
ive added custom version checking code to glibc for gnu indirect support until we can sort stuff out upstream. i wouldnt bother re-keywording sparc with glibc-2.12.1-r1 though as i'm going to do a -r2 soon. you should test and verify that sparc is sane now so that i can do ~sparc when i add -r2. http://sources.gentoo.org/sys-libs/glibc/files/eblits/src_compile.eblit?r1=1.14&r2=1.15 http://sources.gentoo.org/sys-libs/glibc/files/eblits/common.eblit?r1=1.11&r2=1.12
(In reply to comment #27) > ive added custom version checking code to glibc for gnu indirect support until > we can sort stuff out upstream. i wouldnt bother re-keywording sparc with > glibc-2.12.1-r1 though as i'm going to do a -r2 soon. you should test and > verify that sparc is sane now so that i can do ~sparc when i add -r2. Now glibc-2.12.1-r1 works fine with binutils-2.20.1-r1. At least it is able to rebuild binutils, gcc, python and itself without visible breakage.
actually, no revbump as the changes dont warrant it. ive simply re-added ~sparc. thanks for your help in finding the problem.
