+++ This bug was initially created as a clone of Bug #247427 +++ Description of problem: If you run i386-built GDB on x86_64 system it prints error if its (i386) inferior starts to use threading (TLS). Version-Release number of selected component (if applicable): kernel-2.6.9-59.EL.x86_64 (RHEL4-U6-re20070921.2) verified as working on: upstream linux-2.6.22-rc4-git7.x86_64 How reproducible: Always. Steps to Reproduce: 1. gcc -o threadit threadit.c -Wall -ggdb2 -pthread -m32 -static-libgcc 2. gdb ./threadit # threadit is a simple 32-bit pthread_create() program. 3. (gdb) start Actual results: # ./gdb-6.3.0.0-1.153.el4.i386/usr/bin/gdb ./threadit GNU gdb Red Hat Linux (6.3.0.0-1.153.el4rh) ... This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) start Breakpoint 1 at 0x8048497: file threadit.c, line 40. Starting program: /root/jkratoch/redhat/threadit Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0xffffe000 [Thread debugging using libthread_db enabled] Error while reading shared library symbols: Cannot find new threads: generic error Cannot find user-level thread for LWP 32379: generic error (gdb) _ Expected results: $ ./gdb-6.3.0.0-1.153.el4.i386 ./threadit GNU gdb Red Hat Linux (6.3.0.0-1.153.el4rh) ... This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) start Breakpoint 1 at 0x8048497: file threadit.c, line 40. Starting program: /home/short/redhat/rhel46.d/threadit Reading symbols from shared object read from target memory...warning: Lowest section in shared object read from target memory is .hash at ffffe0b4 done. Loaded system supplied DSO at 0xffffe000 [Thread debugging using libthread_db enabled] [New Thread -134945088 (LWP 23820)] [Switching to Thread -134945088 (LWP 23820)] main () at threadit.c:40 40 i = pthread_create (&thread1, NULL, start, NULL); /* create1 */ (gdb) _ Additional info: Original bug was for utrace. This problem happens on ptrace. (unsure): %gs is (probably) read by PTRACE_PEEKUSER as 0 while it is 0x5b. Tested with the same RHEL-4.6 debugger binary + inferior binary on the upstream kernel.
Created attachment 211021 [details] Arbitrary pthread using testcase inferior.
More specific bugreport has been requested.
Created attachment 212201 [details] Standalone C testcase. The problem is really in the x86_64 kernel for i386 processes using ptrace(2). The attached testcase forks a child process, starts threading in it, checks its %gs is !=0, AFTERWARDS the parent process starts ptrace(2)ing the child, reads its %gs by PTRACE_PEEKUSER (offsetof (struct user, regs.gs)) and it reads _0_. libthread_db is not used in this testcase. libpthread is used but if it would leave %gs at 0 a different assertion check would fail there. Steps to Reproduce: 1. gcc -o x86_64-running-i386-debugger x86_64-running-i386-debugger.c -Wall -ggdb2 -pthread -static-libgcc -m32; ./x86_64-running-i386-debugger; echo $? Actual results: x86_64-running-i386-debugger: x86_64-running-i386-debugger.c:149: main: Assertion `gs_orig != 0' failed. Aborted 134 Expected results: 0 Additional info: Not required for the testcase above but %fs/%gs state on libpthread: x86_64 host running i386 binary (no ptrace(2)/debugging involved): main before pthread_create(): fs=0x0 gs=0x5b main after pthread_create(): fs=0x0 gs=0x5b thread: fs=0x0 gs=0x5b i386 host running i386 binary (no ptrace(2)/debugging involved): main before pthread_create(): fs=0x0 gs=0x33 main after pthread_create(): fs=0x0 gs=0x33 thread: fs=0x0 gs=0x33
Use upstream commit e8ed11b9dc07df0134248542ca8e7d40751a6052
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
I've tested the proposed patch and the testcase is still not successful. It fails in gs_to_idx because of an unexpected value of gs (0x5b - FS_TLS_SEL instead of GS_TLS_SEL?) [root@xxx ~]# gcc -o x86_64-running-i386-debugger x86_64-running-i386-debugger.c -Wall -ggdb2 -pthread -static-libgcc -m32; ./x86_64-running-i386-debugger; echo $? gs == 0x5b x86_64-running-i386-debugger: x86_64-running-i386-debugger.c:78: gs_to_idx: Assertion `0' failed. Aborted 134
Comment on attachment 212201 [details] Standalone C testcase. Jerome, you are right, only the testcase was incomplete. Up-to-date version (patched kernel-smp-2.6.9-68.20.EL.x86_64 PASSes there): http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/tests/ptrace-tests/test s/x86_64-ia32-gs.c?cvsroot=systemtap
Posted: http://post-office.corp.redhat.com/archives/rhkernel-list/2008-March/msg00414.html
Committed in 68.27.EL . RPMS are available at http://people.redhat.com/vgoyal/rhel4/
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2008-0665.html