Re: Crash during build on UltraSPARC, 32-bit glibc

[Balint Cristian <rezso at rdsor dot ro>]

Hi,

No problems here with latest RH rawhide glibc-2.3.2-91.src.rpm:

ftp://ftp.rdsor.ro/pub/Linux/Distributions/Aurora/rawhide/sparc/*-2.3.2-91.sparc{v9,64}.rpm newer than 2003-07-15.
	Never encountered crash at building, but dunno how this idea helps you.

	It works for a month after install without any problem, crash or else strange thing.

	BTW was compiled with RH latest binutils/glibc and sparcv9 package one is nptl enabled
was compiled against 2.6.0 headers, compiles and works too.

In weekend will try glibc-2.3.2-98.src.rpm wich is little newer, but require time to build up whole 3
distinct package 32bitv8/32bitv9+nptl/64bitv9.

Can't tell what ./configure params used, you can try yourself from .spec


On Tuesday 21 October 2003 21:36, Nix wrote:
> This crash happens with both glibc-2.3.2 and glibc-2.3.2+debian's
> 2.3.2-8.diff (roughly CVS as of 2003-07-15 with a few extra patches,
> none affecting black magic areas like ld.so.)
>
> Building glibc with gcc-3.3.x (I've seen it with 3.3, 3.3.1, and 3.3.2),
> and binutils-2.14.90.0.6 (I've seen it with earlier versions too),
> I get a segfault when rpcgen runs (i.e., the first time anything is
> run with the new glibc).
>
> No NPTL is used: configuration and building done via this (staid and
> pedestrian) script:
>
> ,----
>
> | #!/bin/sh
> |
> | # Set up the kernel headers. asm/ is *synthetic*; an amalgam of 64-bit
> | and # 32-bit headers, with autoswitching based upon compilation universe.
> |
> | (cd /lib/modules/`uname -r`/build && ./generate-asm.sh include)
> |
> | unset CONFIG_SITE
> | export CFLAGS="-O2 -g -mcpu=ultrasparc -mtune=ultrasparc -pipe"
> | export ASFLAGS="-O2 -g -mcpu=ultrasparc -mtune=ultrasparc -pipe"
> | sparc32 /usr/packages/glibc/core/configure --prefix=/usr --with-fp
> | --with-elf --enable-shared --disable-omitfp --enable-profile
> | --disable-bounded --enable-add-ons --enable-kernel=2.4.22 sparc32 make
> | ASFLAGS-.os="-O2 -g -mcpu=ultrasparc -mtune=ultrasparc -pipe"
>
> `----
>
> (It also segfaults with -march=v8, -mcpu=ultrasparc, and may segfault
> with other lesser flags too; not checked yet.)
>
> (generate-asm.sh is nicked from Debian, RH, and everyone else. It does
> the expected trickery to make a dual-universe kernel header tree.)
>
> Debugging shows
>
> ,----
>
> | amaterasu 458 /usr/packages/glibc/sparc-amaterasu% gdb --args elf/ld.so
> | --library-path elf sunrpc/rpcgen GNU gdb 6.0
>
> [snip warranty info]
>
> | This GDB was configured as "sparc-unknown-linux-gnu"...
> | (gdb) break _dl_sysdep_read_whole_file
> | Breakpoint 1 at 0xdc88: file dl-misc.c, line 58.
> | (gdb) run
> | Starting program: /usr/packages/glibc/sparc-amaterasu/elf/ld.so
> | --library-path elf sunrpc/rpcgen Breakpoint 1 at 0x800dc88: file
> | dl-misc.c, line 58.
> |
> | Breakpoint 1, _dl_sysdep_read_whole_file (file=0x8015fa0
> | "/etc/ld.so.preload", sizep=0xefffef74, prot=3) at dl-misc.c:58 58       
> | int fd = __open (file, O_RDONLY);
> | (gdb) bt
> | #0  _dl_sysdep_read_whole_file (file=0x8015fa0 "/etc/ld.so.preload",
> | sizep=0xefffef74, prot=3) at dl-misc.c:58 #1  0x08002cb4 in dl_main
> | (phdr=0x10034, phnum=65780, user_entry=0x0) at rtld.c:980 #2  0x0801061c
> | in _dl_sysdep_start (start_argptr=0x10034, dl_main=0x100f4) at
> | dl-sysdep.c:233
>
> (Things look reasonable here, in the first call to
> _dl_sysdep_read_whole_file() in ld.so, but...)
>
> | (gdb) step
> |
> | Program received signal SIGSEGV, Segmentation fault.
> | 0x0801234c in __syscall_error_handler ()
> | (gdb) bt
> | #0  0x0801234c in __syscall_error_handler ()
> | #1  0x0800dc90 in _dl_sysdep_read_whole_file (file=0x2 <Address 0x2 out
> | of bounds>, sizep=0xefffef74, prot=3) at dl-misc.c:58 #2  0x08002cb4 in
> | dl_main (phdr=0x8015fa0, phnum=4026527604, user_entry=0x3) at rtld.c:980
>
> `----
>
> (boom. Something smashed the stack. Hard. Everything above the `file'
> parameter to _dl_sysdep_read_whole_file() is garbaged, including the
> args to dl_main. Small wonder it crashed.)
>
> rtld and friends are slightly black-magic to me, I'm afraid: I guess
> that something's gone fubared with relocation, since it looks like this
> is the first inter-translation-unit function call in rtld; but I don't
> know enough about the relocation dance to guess what that might be.
>
> Am I on the right track? Has someone else squashed this already?
> Or is my cold causing me to hallucinate problems where there are
> none?