Description of problem:
The 32-bit libthread_db included in the latest glibc breaks 32-bit gdb running
on a 64-bit kernel. At first I thought it was something broken in the new gdb,
but then I took gdb-188.8.131.52-1.122.i386 from FC5 and a threaded program built on
FC5 and tried it on rawhide/x86_64, and the symptom is the same as using the
latest gdb.i386 on rawhide/x86_64:
[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 19788: generic error
The problem is that td_ta_thr_iter_p() returns 1 instead of 0, for some reason I
haven't tried to figure out yet.
gdb.x86_64 works perfectly well, and the latest gdb.i386 works perfectly on
rawhide/i386, on kernel.i686.
Version-Release number of selected component (if applicable):
kernel-2.6.17-1.2364.fc6, and also whatever kernel runs on the brew i386 build
machines, which is how I know it is not a kernel problem. I can tell from the
failures that it is an x86_64 kernel.
Steps to Reproduce:
1.Install gdb.i386 on x86_64 rawhide
2.Try to debug any 32-bit threaded program, setting a breakpoint in main
It should not fail
32-bit gdb ever worked on 64-bit x86-64 kernel? That's news for me.
Yes, I have used it in the not-too-distant past, even to debug multi-threaded
programs and to run its testsuite.
And I've just verified that it works on FC5/x86_64 with all updates and testing
updates as of yesterday.
Sorry, false alarm, it's not in glibc, it's in the kernel. sys_ptrace32
regressed in this regard between the FC5 kernel and the rawhide kernel, in that
the latter no longer handles PTRACE_[SG]ET_THREAD_AREA. I don't quite see that
the handling in the FC5 kernel is entirely correct, but, oddly enough, it
appears to work. Anyhow, this makes it a kernel bug, and apparently a
regression while at that.
Fixed upstream in Nov 2006.