Glibc 2.2.4-2 Woes...

M,

I see what you mean now.
I have glibc 2.2.4-2 compiling all the way to the point where it starts churning thorugh:

make -C sunrpc others
make[2]: Entering directory `/home/carlos/palinux/glibc-2.2.4/glibc-2.2.4/sunrpc'
/home/carlos/palinux/glibc-2.2.4/hppa-linux/obj/elf/ld.so.1 --library-path /home/carlos/palinux/glibc-2.2.4/hppa-linux/obj:/home/carlos/palinux/glibc-2.2.4/hppa-linux/obj/math:/home/carlos/palinux/glibc-2.2.4/hppa-linux/obj/elf:/home/carlos/palinux/glibc-2.2.4/hppa-linux/obj/dlfcn:/home/carlos/palinux/glibc-2.2.4/hppa-linux/obj/nss:/home/carlos/palinux/glibc-2.2.4/hppa-linux/obj/nis:/home/carlos/palinux/glibc-2.2.4/hppa-linux/obj/rt:/home/carlos/palinux/glibc-2.2.4/hppa-linux/obj/resolv:/home/carlos/palinux/glibc-2.2.4/hppa-linux/obj/crypt:/home/carlos/palinux/glibc-2.2.4/hppa-linux/obj/linuxthreads /home/carlos/palinux/glibc-2.2.4/hppa-linux/obj/sunrpc/rpcgen -Y gcc -print-file-name=cpp | sed 's|/cpp$||' -c rpcsvc/bootparam_prot.x -o /home/carlos/palinux/glibc-2.2.4/hppa-linux/obj/sunrpc/xbootparam_prot.T

At which point I've followed ld down with gdb to:

0x41003198 <_dl_start+1584>: copy r1,r20
0x4100319c <_dl_start+1588>: addil 0,r19,%r1
0x410031a0 <_dl_start+1592>: copy r1,r21
0x410031ac <_dl_start+1604>: ldw 2c(sr0,r21),r21
0x410031b0 <_dl_start+1608>: copy r1,r23
0x410031b4 <_dl_start+1612>: copy r20,r26

0x410031b8 <_dl_start+1616>:    ldw 30(sr0,r23),r23
0x410031bc <_dl_start+1620>:    b,l 0x41012b70 <__assert_fail>,rp
0x410031c0 <_dl_start+1624>:    copy r21,r25
0x410031c4 <_dl_start+1628>:    addil 0,r19,%r1

The assertion fails.
The address in r21/r25 is 0x15b78, which is clearly not a valid address, and thus dl's printf barfs.

I will add that the address is not always 0x15b78, and it varies. Which might mean that it's just random stuff being pulled off the stack (or I haven't been that thorough in tracing the assembly).

#0 _dl_debug_vdprintf (fd=0, tag_p=0, fmt=0x17c94 <Address 0x17c94 out of bounds>,

    arg=0xbff008d8) at dl-misc.c:101
#1  0x4100ebc8 in _dl_dprintf (fd=2, fmt=0x17c94 <Address 0x17c94 out of bounds>)
    at dl-misc.c:279
#2  0x41012bd0 in __assert_fail (assertion=0x15b64 <Address 0x15b64 out of bounds>,
    file=0x0, line=62, function=0xbff008d8 "") at dl-minimal.c:190

#3 0x410031c4 in _dl_start (arg=0xbff004f4) at rtld.c:62 #4 0x41002ae8 in _dl_start_user () at rtld.c:143

Program received signal SIGSEGV, Segmentation fault. _dl_debug_vdprintf (fd=0, tag_p=0, fmt=0x17c94 <Address 0x17c94 out of bounds>,

    arg=0xbff008d8) at dl-misc.c:101

101 while (*fmt != '\0')

I'm completely confused by the usage of the registers. But that's compiler tuned assembly for you :)

It's not something that clearly jumps out at you, and after tracing about the assembly, trying to follow what goes where, It is not any clearer.

It's not a blatently obvious mistake :}

---

I've also noticed that the tests for glibc bail out with:

./tst-iconv1: error while loading shared libraries: ./tst-iconv1: symbol __deregister_frame_info, version GLIBC_2.2 not defined in file libc.so.6 with link time reference

Does __deregister_frame_info and __register_frame_info have to do with the stack unwinding for DWARF2 vsyscalls?

Both of these functions have weak bindings, and I remember there being some odd rules about bidning in dl_main.

---

c.

I got the new gcc to build (3.0.2 cvs 20010922) and tried glibc again... it dies similarly while trying to run ld.so ...

Program received signal SIGSEGV, Segmentation fault. _dl_debug_vdprintf (fd=0, tag_p=0,

    fmt=0x17cdc <Address 0x17cdc out of bounds>, arg=0xbff005d8)
    at dl-misc.c:101
101       while (*fmt != '\0')
(gdb) bt
#0  _dl_debug_vdprintf (fd=0, tag_p=0, 
    fmt=0x17cdc <Address 0x17cdc out of bounds>, arg=0xbff005d8)
    at dl-misc.c:101
#1  0x4100eb68 in _dl_dprintf (fd=2, 
    fmt=0x17cdc <Address 0x17cdc out of bounds>) at dl-misc.c:279
#2  0x41012b6c in __assert_fail (
    assertion=0x15bac <Address 0x15bac out of bounds>, file=0x0, line=62, 
    function=0xbff005d8 "") at dl-minimal.c:190

#3 0x410031d4 in _dl_start (arg=0xbff00224) at rtld.c:62 #4 0x41002af8 in _dl_start_user () at rtld.c:143

I'll try to debug it some more tomorrow.

BenC (debian's glibc maintainer) also claims that the hppa patch in glibc breaks linuxthreads (runtime) on other architectures. Does anyone know anything about this?

randolph

   @..@                                         http://www.TauSq.org/
  (----)
 ( >__< )
 ^^ ~~ ^^