GNU/Hurd: ld.so.1 crashes while resolving symbols

GNU/Hurd: ld.so.1 crashes while resolving symbols

[Andrea Monaco]

After successfully building latest glibc, I test it with the following:

  GLIBC=/root/glibc/build

  GCONV_PATH=${GLIBC}/iconvdata LD_DEBUG=all LC_ALL=C
  ${GLIBC}/elf/ld.so.1 --library-path
  ${GLIBC}:${GLIBC}/math:${GLIBC}/elf:${GLIBC}/dlfcn:${GLIBC}/nss:${GLIBC}/nis:${GLIBC}/rt:${GLIBC}/resolv:${GLIBC}/crypt:${GLIBC}/nptl:${GLIBC}/dfp:${GLIBC}/mach:${GLIBC}/hurd
  /root/glibc/bug-fstat


Shared objects are found and linked, but then the loader crashes.
Here's the last part of the output


         0:     symbol=__access_noerrno;  lookup in file=./bug-fstat [0]
         0:     symbol=__access_noerrno;  lookup in file=/root/glibc/build/libc.so.0.3 [0]
         0:     binding file /root/glibc/build/elf/ld.so.1 [0] to /root/glibc/build/libc.so.0.3 [0]: normal symbol `__access_noerrno' [GLIBC_PRIVATE]
         0:     symbol=_dl_init_first;  lookup in file=./bug-fstat [0]
         0:     symbol=_dl_init_first;  lookup in file=/root/glibc/build/libc.so.0.3 [0]
         0:     binding file /root/glibc/build/elf/ld.so.1 [0] to /root/glibc/build/libc.so.0.3 [0]: normal symbol `_dl_init_first' [GLIBC_PRIVATE]
         0:     symbol=_dl_signal_error;  lookup in file=./bug-fstat [0]
         0:     symbol=_dl_signal_error;  lookup in file=/root/glibc/build/libc.so.0.3 [0]
         0:     binding file /root/glibc/build/elf/ld.so.1 [0] to /root/glibc/build/libc.so.0.3 [0]: normal symbol `_dl_signal_error' [GLIBC_PRIVATE]
         0:     symbol=__errno_location;  lookup in file=./bug-fstat [0]
         0:     symbol=__errno_location;  lookup in file=/root/glibc/build/libc.so.0.3 [0]
         0:     binding file /root/glibc/build/elf/ld.so.1 [0] to /root/glibc/build/libc.so.0.3 [0]: normal symbol `__errno_location' [GLIBC_2.2.6]
         0:     symbol=__writev;  lookup in file=./bug-fstat [0]
         0:     symbol=__writev;  lookup in file=/root/glibc/build/libc.so.0.3 [0]
         0:     binding file /root/glibc/build/elf/ld.so.1 [0] to /root/glibc/build/libc.so.0.3 [0]: normal symbol `__writev' [GLIBC_2.2.6]
Killed


"bug-fstat" is my test program, but every program I tried does the same,
it crashes right after finding symbol "__writev".

After many printf, I singled out the exact instruction that causes the
crash, which is line 361 in sysdeps/i386/dl-machine.h (marked with >>):


      switch (r_type)
        {
# ifndef RTLD_BOOTSTRAP
        case R_386_SIZE32:
          /* Set to symbol size plus addend.  */
          *reloc_addr += sym->st_size;
          break;
# endif
        case R_386_GLOB_DAT:
        case R_386_JMP_SLOT:
>>        *reloc_addr = value;
          break;


Is this obvious?  Even if I made mistakes while building, I don't think
a crash is expected.



Thanks,

Andrea Monaco

Re: GNU/Hurd: ld.so.1 crashes while resolving symbols

[Samuel Thibault]

Hello,

Andrea Monaco via Libc-alpha, le mer. 15 déc. 2021 19:30:19 +0100, a ecrit:
>   GLIBC=/root/glibc/build
> 
>   GCONV_PATH=${GLIBC}/iconvdata LD_DEBUG=all LC_ALL=C
>   ${GLIBC}/elf/ld.so.1 --library-path
>   ${GLIBC}:${GLIBC}/math:${GLIBC}/elf:${GLIBC}/dlfcn:${GLIBC}/nss:${GLIBC}/nis:${GLIBC}/rt:${GLIBC}/resolv:${GLIBC}/crypt:${GLIBC}/nptl:${GLIBC}/dfp:${GLIBC}/mach:${GLIBC}/hurd
>   /root/glibc/bug-fstat

Rather than specifying all of this by hand, use the testrun.sh script
that is generated when running make check. Notably you are using a line
that is valid for Linux only (nptl).

Samuel

Re: GNU/Hurd: ld.so.1 crashes while resolving symbols

[Andrea Monaco]

  > Rather than specifying all of this by hand, use the testrun.sh
  > script that is generated when running make check.


Thanks!  Using the script solved the issue.

But it was LD_DEBUG=all that caused the crash.  LD_DEBUG makes the
loader verbose, and it takes many values turning on various classes of
messages; "all" activates them all.  More specifically, I found out that
the values of "bindings", "reloc" and "symbols" to LD_DEBUG make the
loader crash, while the others don't.

I got the same behavior on my already installed glibc, so it's a true
bug of glibc on GNU/Hurd.



Cheers,

Andrea Monaco