Compiling a small test app that uses threads and TLS with gcc generates a problematic executable. When executed gets killed by SIGILL signal (illegal operand). Trying to see what dynamic libraries is linked to with ldd, ldd returns a "not a dynamic executable). Reproducible: Always Steps to Reproduce: 1.gcc -Wall -o 2../test.threads 3. Actual Results: Bash returns a "killed". Executing it thru valgrind (gdb is not emerged, trying to get more info) says gets killed by SIGILL signal (illegal operand) Expected Results: Normal program execution This happens in a newly emerged system (with portage tree of just three days old). Installed from stage 0. emerge info output: ------------------- Gentoo Base System version 1.6.13 Portage 2.0.51.22-r2 (default-linux/x86/2005.0, gcc-3.4.4, glibc-2.3.5-r1, 2.6.12-gentoo-r7 i586) ================================================================= System uname: 2.6.12-gentoo-r7 i586 AMD-K6(tm) 3D processor dev-lang/python: 2.3.4-r1, 2.4.1-r1 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i586-pc-linux-gnu" CFLAGS="-march=k6-2 -m3dnow -mmmx -fomit-frame-pointer -pipe" CHOST="i586-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=k6-2 -m3dnow -mmmx -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS=" http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/ http://gentoo.blueyonder.co.uk http://ftp.heanet.ie/pub/gentoo/ http://linuv.uv.es/mirror/gentoo/ http://mir.zyrianes.net/gentoo/ http://pandemonium.tiscali.de/pub/gentoo/ http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ http://ftp.du.se/pub/os/gentoo http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://gentoo.inode.at/ http://ftp.snt.utwente.nl/pub/os/linux/gentoo http://www.mirrorservice.org/sites/www.ibiblio.org/gentoo/ http://gentoo.inf.elte.hu/ http://ftp.caliu.info/pub/gentoo/ " MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 ncurses nls nptl pam pic unicode userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS ------------------- libc version (execution of /lib/libc.so.6): ------------------- GNU C Library stable release version 2.3.5, by Roland McGrath et al. Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 3.4.4 (Gentoo 3.4.4, ssp-3.4.4-1.0, pie-8.7.8). Compiled on a Linux 2.6.11 system on 2005-08-13. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.10 by Xavier Leroy The C stubs add-on version 2.1.2. GNU Libidn by Simon Josefsson BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk For bug reporting instructions, please see: <http://www.gnu.org/software/libc/bugs.html>. ------------------- This one with libpthread. NPTL version in /lib/tls/libc.so.6; more on this file later. The problem started some days ago when, after having completely installed the system (including Xorg), after emerging nvidia-glx trying to execute a glxinfo gave a quite interesting error: ./libc.so.6: error while loading shared libraries: unexpected reloc type 0x0e Also glx X extension was not being loaded. Then we decided to reinstall the system from stage 0. Now we have a clean Gentoo installation just after the restart with our own kernel. Trying to execute /lib/tls/libc.so.6 gives again the a reloc error, /lib/tls/libc.so.6 execution output: ------------------- ./libc.so.6: error while loading shared libraries: unexpected reloc type 0x0e ------------------- while the output of /lib/libc.so.6 gives the usual output (see before). Trying to do a ldd, ldd says it's not a dynamic executable. So apparently there is a big problem with NPTL. We did a pthread test .c (mmm... not exactly. We copied an example from the Daniel Robbins pthreads IBM tutorial ;) to see if NPTL was causing problems. Compiling threads.test.c (without using TLS) and executing it shows no problem. Normal execution no errors. ldd shows it was linked with: ldd ./thread.test output: ------------------- linux-gate.so.1 => (0xffffe000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7ee1000) libc.so.6 => /lib/libc.so.6 (0xb7dd4000) /lib/ld-linux.so.2 (0xb7f37000) ------------------- We wanted to test TLS (by making the int of the thread function static and __thread). Compiles OK, but trying to execute it gives an "Killed" message by Bash. Running it thru Valgrind shows this: valgrind ./thread.test (now with TLS) output: ------------------- ==6559== Memcheck, a memory error detector. [...] ==6559== Process terminating with default action of signal 4 (SIGILL) ==6559== Illegal operand at address 0xB0041868 ==6559== at 0x8048140: (within /root/threads) [...] Illegal instruction ------------------- Trying to do a ldd on the executable, ldd says again it's not a dynamic executable. So summarizing: Execution of /lib/libpthread.so.0 -> Segfaults Execution of /lib/libc.so.6 -> OK (Libc 2.3.5 with libpthread, no TLS support) Execution of /lib/tls/libc.so.6 -> Error loading shared libs (reloc) ldd of /lib/tls/libc.so.6 -> Not a dynamic executable Execution of test program (uses Pthreads) -> OK (linked with /lib/libc.so.6) Execution of test program (uses Pthreads + TLS) -> Killed ldd of test program (uses Pthreads + TLS) -> Not a dynamic executable SO apparently any program linked with NPTL and with TLS support is broken in this arch and using this GCC. We don't know if this is a problem of gcc or a problem of glib, but we're using latest versions.
Created attachment 65884 [details] Test c code using pthreads and TLS
Mmm... I made two errors, sorry. First, in steps to reproduce: 1.gcc -Wall -o thread.test tread.test.c -lpthread 2../thread.test Second (but obvious), system is installed from stage1.
worksforme with the same gcc and binutils... Plus: $ ldd /lib/tls/libc.so.6 /lib/ld-linux.so.2 (0x55555000) linux-gate.so.1 => (0xffffe000) I'm wondering if it's a problem with your system.
Are you with a similar microprocessor? It's all being compiled with the -march=k6-2 ... Can be gcc generating invalid instructions for this micro? The system is apparently OK (I'm talking about hardware), as half a year ago we discovered some hardware problem in the memory bootstraping Gentoo and memory was changed. That time the rest of the system was tested and everything seemed to be OK. System memory should be OK, as after your reply we made a memtest (6 hours running) and no apparently problems appear. SMART says discs are OK, no other errors showed by the kernel and the system is stable. As we have said it's the second time we try to install gentoo from stage1 with the same final behaviour of the NPTL libpthread library, while the linuxthreads one without TLS is working perfectly. That's what surprised us. Is there something we can try to find if gcc or binutils is generating broken code? We have another slower K6-2 system, and we'll try compiling Gentoo from stage 1 the same way we're doing in this system with the NTPL + TLS problem to see if it's reproducible.
Have you tried -march=i586?
Confirmed in my own system. K6-2 400 MHz on an Asus P5A. I'm seeing the same behaviour as the reporter. Today I decided to test if this was happening to my computer, and decided to test it doing a chroot in a file test partition under my current Gentoo install in that system (is from January this year). The steps I made to reproduce: 1.- Created a 4 GByte file to gave it format with mkfs.ext3 2.- Mounted with loop in /mnt/gentoo 3.- Started a clean Gentoo install 4.- Following Gentoo guide (...) 5.- Bootstrapped 6.- JUST after bootstrapping tested execution of /lib/libc.so.6 and /lib/tls/libc.so.6, as the glibc installed during bootstrap seemed to be compiled with linuxthreads and NPTL (the later with TLS). Guess what? Same behaviour! /lib/libc.so.6 works but /lib/tls/libc.so.6 has problem with reloc!! I haven't continued during the full emerge -e system, as I think this just confirms the problem. Binutils? Gcc? Glibc? Here is my emerge info: Gentoo Base System version 1.12.0_pre5 Portage 2.0.51.22-r2 (default-linux/x86/2005.0, gcc-3.4.4, glibc-2.3.5-r1, 2.6.12-gentoo-r7 i586) ================================================================= System uname: 2.6.12-gentoo-r7 i586 AMD-K6(tm) 3D processor dev-lang/python: 2.3.4-r1 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: [Not Present] sys-devel/automake: [Not Present] sys-devel/binutils: 2.16.1 sys-devel/libtool: [Not Present] virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i586-pc-linux-gnu" CFLAGS="-O2 -march=k6-2 -fomit-frame-pointer -pipe" CHOST="i586-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=k6-2 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" LC_ALL="es_ES.UTF-8" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://192.168.0.2/gentoo-portage" USE="x86 ncurses nls nptl pam pic unicode userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LDFLAGS, LINGUAS, PORTDIR_OVERLAY This system is syncing to a local mirror. It was updated one day ago, so this is the age of the portage tree from what this test install was done.
Recompiled this afternoon glibc with make.conf cflags="-pipe". No optimizations, no march, no fomit-frame-pointer. Nothing. Result? Same behaviour. So ... I think we can rule out gcc as the problem here. What more can I test?
try doing this: *WARNING: when i say 'cp' i mean 'cp' and when i say 'mv' i mean 'mv' ... using 'cp' instead of 'mv' can break your box # rm -rf /var/tmp/portage # FEATURES=keepwork emerge glibc # cp -a /lib/ld-linux.so.2 /lib/ld-linux.so.2.old # cp -a /var/tmp/portage/glibc-*/work/build*nptl/elf/ld.so \ /lib/ld-linux.so.2.new # mv /lib/ld-linux.so.2.new /lib/ld-linux.so.2 if your system blows up at this point, you can recover by doing: # bb # mv /lib/ld-linux.so.2.old /lib/ld-linux.so.2 if your system doesnt blow up, see if you can now run /lib/tls/libc.so.6 btw, your test of trying to run any lib in /lib other than libc.so.6 is invalid as libc.so has certain magic added to it so that you can execute it and see the pretty version output
well get back to us please
