Hello,
Here's another update on this issue.
It was very tricky to find what was going on in the loader because
at the point of failure the backtrace produced by GDB was not
complete. (not to mention the first ones were nonsense)
Samuel, you were right in suggesting a long recursion. :)
Even though the incomplete traces wouldn't show it, the control flow
follows the pattern given below.
I set a breakpoint at '_dl_runtime_resolve' and run the program. The
loader prints some stuff and breaks, after binding the symbol
'_hurd_intr_rpc_mach_msg', just before crashing (I can consider myself
very lucky), while resolving '__mach_msg'. I stepi/nexti until
'__io_write'.
#9 ??
#8 _dl_runtime_resolve
#7 _dl_fixup
#6 _dl_lookup_symbol_x
#5 _dl_debug_bindings
#4 _dl_debug_printf
#3 _dl_debug_vdprintf
#2 _dl_writev
#1 __writev
#0 __io_write
Above is the reversed stacktrace[1]. This is where the recursion
starts; '__io_write' is about to execute the following instruction:
=> 0x0001b11c <__io_write+316>: call 0x1cc0 <_hurd_intr_rpc_mach_msg@plt>
I stepi and get the following instruction:
=> 0x00001cc0 <_hurd_intr_rpc_mach_msg@plt+0>: jmp *0x44(%ebx)
When I stepi again, the stacktrace is lost:
(gdb) bt
#0 0x01073990 in ?? ()
Backtrace stopped: Cannot access memory at address 0x3
but executing a few more stepi commands leads me back to
'_dl_runtime_resolve', again trying to resolve '__mach_msg':
(gdb) bt
#0 _dl_lookup_symbol_x (
undef_name=undef_name@entry=0x10483b3 "__mach_msg",
undef_map=undef_map@entry=0x10327f0, ref=ref@entry=0x102b13c,
symbol_scope=0x10329a8, version=0x1239150, type_class=1, flags=5,
skip_map=0x0) at dl-lookup.c:806
#1 0x0000f008 in _dl_fixup (l=0x10327f0, reloc_arg=<optimized out>)
at dl-runtime.c:111
#2 0x00015c80 in _dl_runtime_resolve ()
at ../sysdeps/i386/dl-trampoline.S:43
#3 0x01073ae3 in ?? ()
So, it looks like '_hurd_intr_rpc_mach_msg' is not being corretly
resolved in the loader's code, right? Although, I'm puzzled about why
all the previous messages were printed successfully.
Another behaviour I noticed, and which may be related, is that after
getpid is bound the debugging messages no longer show the process id
and instead 0 is written[2].
Regards,
Diego
---
[1] This is the full stacktrace at that point:
(gdb) bt
#0 0x0001b11c in __io_write (io_object=142,
data=0x102ba78 " 0:\tbinding file /lib/i386-gnu/libc.so.0.3 [0]
to /lib/i386-gnu/libc.so.0.3 [0]: normal symbol `__mach_msg'",
dataCnt=115, offset=-1, amount=0x102bb14)
at
/build/glibc-oM87wD/glibc-2.22/build-tree/hurd-i386-libc/hurd/RPC_io_write.c:171
#1 0x0001780a in __writev (fd=<optimized out>, iov=<optimized out>,
niov=<optimized out>) at ../sysdeps/mach/hurd/dl-sysdep.c:429
#2 0x00010643 in _dl_writev (niov=14, iov=0x102bbc8, fd=2)
at ./dl-writev.h:54
#3 _dl_debug_vdprintf (fd=2, tag_p=-1, tag_p@entry=1, fmt=0x2200d "",
fmt@entry=0x21fdc "binding file %s [%lu] to %s [%lu]: %s symbol `%s'",
arg=0x102be24 "") at dl-misc.c:244
#4 0x00010a59 in _dl_debug_printf (
fmt=0x21fdc "binding file %s [%lu] to %s [%lu]: %s symbol `%s'")
at dl-misc.c:255
#5 0x0000a72b in _dl_debug_bindings (protected=0, type_class=1,
version=0x1239150, value=0x102be68, ref=0x102bef4,
undef_map=0x10327f0, undef_name=0x10483b3 "__mach_msg")
at dl-lookup.c:1005
#6 _dl_lookup_symbol_x (
undef_name=undef_name@entry=0x10483b3 "__mach_msg",
undef_map=undef_map@entry=0x10327f0, ref=ref@entry=0x102bef4,
symbol_scope=0x10329a8, version=0x1239150, type_class=1, flags=5,
skip_map=0x0) at dl-lookup.c:940
#7 0x0000f008 in _dl_fixup (l=0x10327f0, reloc_arg=<optimized out>)
at dl-runtime.c:111
#8 0x00015c80 in _dl_runtime_resolve ()
at ../sysdeps/i386/dl-trampoline.S:43
#9 0x01073ae3 in ?? ()
[2]
$ LD_DEBUG=bindings /bin/ls
...
1334: binding file /lib/ld.so [0] to /lib/ld.so [0]: normal symbol
`_r_debug' [GLIBC_2.2.6]
1334: binding file /lib/ld.so [0] to /bin/ls [0]: normal symbol
`free' [GLIBC_2.2.6]
1334: binding file /lib/ld.so [0] to /lib/i386-gnu/libc.so.0.3 [0]:
normal symbol `__getpid' [GLIBC_2.2.6]
0: binding file /lib/ld.so [0] to /lib/ld.so [0]: normal symbol
`_dl_find_dso_for_object' [GLIBC_PRIVATE]
...
