Bugzilla Bug 46186

gdb runs without thread support unless I do FEATURES="nostrip" emerge glibc.

I found this solution from the following forums:
http://forums.gentoo.org/viewtopic.php?t=147172
http://forums.gentoo.org/viewtopic.php?t=153520

Apparently the glibc ebuild should ensure that /lib/libthread_db-1.0.so is not stripped.

Reproducible: Always
Steps to Reproduce:
1.debug a program with gdb


Actual Results:  
thread operations like "info threads" fail; signals like SIGSEGV are not caught
by gdb

Expected Results:  
gdb should operate with full thread and signal support enabled

Portage 2.0.50-r1 (default-x86-2004.0, gcc-3.3.2, glibc-2.3.3_pre20040207-r0, 2.
6.5-rc2)
=================================================================
System uname: 2.6.5-rc2 i686 Intel(R) Pentium(R) 4 CPU 3.20GHz
Gentoo Base System version 1.4.3.13
Autoconf: sys-devel/autoconf-2.58-r1
Automake: sys-devel/automake-1.7.7
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CFLAGS="-O3 -march=pentium4 -mmmx -msse -msse2 -mfpmath=sse -fomit-frame-pointer
 -pipe"
CHOST="i686-pc-linux-gnu"
COMPILER="gcc3"
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/s
hare/config /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O3 -march=pentium4 -mmmx -msse -msse2 -mfpmath=sse -fomit-frame-point
er -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs ccache sandbox"
GENTOO_MIRRORS="http://mirror.pacific.net.au/gentoo/"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY=""
SYNC="rsync://mirror.pacific.net.au/gentoo-portage"
USE="X Xaw3d aalib acpi avi berkdb crypt cups encode fastcgi firebird foomaticdb
 gdbm gif gpm gtk2 imap imlib java jpeg ldap libg++ libwww mad mikmod mmx mozcal
endar mozilla mpeg ncurses nls nogjc nptl oggvorbis oss pam pdflib perl png pyth
on qt quicktime readline samba sasl sdl slang spell sse sse2 ssl tcpd tiff tls t
ruetype x86 xml2 xmms zlib"

I have done some tests compiling:

As per Bug 45756 I compiled glibc with CFLAGS="-march=i686 -O3 -pipe" and installed it into a chroot.

I then used a test program (attached). It just creates threads.

When run though gdb on the unstripped system I get:
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".
 
(gdb) r
Starting program: /test
[Thread debugging using libthread_db enabled]
[New Thread 1073843040 (LWP 24186)]
[New Thread 1083554736 (LWP 24189)]
created thread 0
[New Thread 1091951536 (LWP 24190)]
created thread 1
[New Thread 1100344240 (LWP 24191)]
created thread 2
[New Thread 1108736944 (LWP 24192)]
created thread 3
[New Thread 1117129648 (LWP 24193)]
created thread 4
[New Thread 1125522352 (LWP 24194)]
created thread 5
[New Thread 1133915056 (LWP 24195)]
created thread 6
[New Thread 1142307760 (LWP 24196)]
created thread 7
[New Thread 1150700464 (LWP 24197)]
created thread 8
[New Thread 1159093168 (LWP 24198)]
created thread 9
[New Thread 1167485872 (LWP 24199)]
created thread 10
[New Thread 1175878576 (LWP 24200)]
created thread 11
[New Thread 1184271280 (LWP 24201)]
created thread 12
[New Thread 1192663984 (LWP 24202)]
created thread 13
[New Thread 1201056688 (LWP 24203)]
created thread 14
[New Thread 1209449392 (LWP 24204)]
created thread 15
[New Thread 1217842096 (LWP 24205)]
created thread 16
[New Thread 1226234800 (LWP 24206)]
created thread 17
[New Thread 1234627504 (LWP 24207)]
created thread 18
[New Thread 1243020208 (LWP 24208)]
created thread 19
 
Program exited normally.

Note the "New Thread XXXX" lines.

Doing:
saj lib # strip --strip-unneeded libc-2.3.3.so
saj lib # strip --strip-unneeded libm-2.3.3.so
does not effect the output.

But when I do:
saj lib # strip --strip-unneeded libpthread-0.60.so
I now get the bad gdb output:
GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".
 
(gdb) r
Starting program: /test
created thread 0
created thread 1
created thread 2
created thread 3
created thread 4
created thread 5
created thread 6
created thread 7
created thread 8
created thread 9
created thread 10
created thread 11
created thread 12
created thread 13
created thread 14
created thread 15
created thread 16
created thread 17
created thread 18
created thread 19
 
Program exited normally.

Note no "New Thread" lines.

Thus the glibc libraries should not be stripped.

I will also attach the glibc Fedora RPM spec for referance on what files can be stripped.

Created an attachment (id=28825) [details]
test.c

A small program which creates threads.
gcc -o test test.c -lpthread to compile

Created an attachment (id=28826) [details]
glibc.spec

Glibc spec file from Fedora.
Note which files are stripped

Maybe using the separate debug information options of gdb6 might help us
here... look at #45150 for portage support.. Remember that fedora ship
-debuginfo files for everything now.. Maybe hardcoding it to use eu-strip in
the glibc ebuild might be a way to fix this..

Could the gdb parts of bug 55146 be related? I am using nostrip, I can see back
traces, but there are obvious problems.

*** Bug 46323 has been marked as a duplicate of this bug. ***

*** Bug 48116 has been marked as a duplicate of this bug. ***

unless someone points out something obvious in the next ~24 hours i'm going to
update the glibc ebuilds to not strip libthread_db

It may help if you read my data first, you need to stop stipping of not just
libpthread_db but libpthread (the normal one) as well.
Run the test after you modified the ebuild as per comment #1
( or I can do it, email me the ebuild or something and I will test )

fixed in glibc-2.2.5-r9, glibc-2.3.2-r10, and glibc-2.3.4.20040619

*** Bug 51117 has been marked as a duplicate of this bug. ***

If I understand things correctly, it still hasn't been correct in
2.3.3.20040420-r2, which was just recently marked stable on x86. So update
world just nearly replaced glibc I custom compiled with FEATURES=nostrip with
glibc containing stripped libpthreads again, if I hadn't stopped it in last
minute. 

As it seems, the only ebuild where this isn't fixed now is this one, which is
the latest stable one on x86. I really wonder why, since it's arguably what
most people will use. So for now I still need to emerge glibc with
FEATURES=nostrip, since downgrading glibc is not really an option, 2.3.4 is
marked ~x86 and I do need thread debugging.

united ~ # emerge glibc -p

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild   R   ] sys-libs/glibc-2.3.4.20041006


united ~ # file /lib/tls/libpthread-2.3.4.so
/lib/tls/libpthread-2.3.4.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped

Some small bug in the glibc install method, if you want to debug nptl ....

united ~ # file /lib/libpthread-0.10.so
/lib/libpthread-0.10.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped

if fine though

Ok,

Here is what is wrong with glibc-2.3.4.20041006:

From emerge log:

mkdir: invalid option -- o
Try `mkdir --help' for more information.
mv: when moving multiple files, last argument must be a directory
Try `mv --help' for more information.
shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
prepallstrip:
shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
strip:
shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
strip:
   lib/tls/libpthread-2.3.4.so
   lib/tls/librt-2.3.4.so
   lib/tls/libm-2.3.4.so
   lib/tls/libthread_db-1.0.so

And:

united glibc-2.3.4.20041006 # ls /var/tmp/portage/glibc-2.3.4.20041006/temp/thread-backup
libpthread-0.10.so  libpthread.so.0  libthread_db-1.0.so  libthread_db.so.1

In the ebuild ::

mkdir -o ${T}/thread-backup/tls

??? -o BUG!!!!!

Fixed a few days ago ...

2.3.3.20040420-r2 still isn't fixed (as per my previous comment), but since
2.3.4.20040808-r1 was recenetly marked stable for x86, it's no longer really an
issue on this architecture. 

Today I tried to debug a threaded program, but failed because gdb uses the
libthread_db library "/lib/tls/libthread_db.so.1" -- which is stipped :-(

As a work-a-round i moved /lib/tls away.

The USE flags of my glibc are only nptl and nls. 

Is it correct that /lib/tls/libpthread-2.3.5.so is stripped but
/lib/libpthread-0.10.so is not? I am really confused ...

See bug #101374

It was fixed but then broke for a few days. (a long time ago)
Try remerging glibc I guess.

( you could check the ebuild in /var/db/pkg/*/glibc* to see if it has the bug I
suppose )

the same problem with glibc 2.6/2.6.1
libpthread is stripped, libthread_db.so is not.
adding nostrip to FEATURES helps

(In reply to comment #19)
> the same problem with glibc 2.6/2.6.1
> libpthread is stripped, libthread_db.so is not.
> adding nostrip to FEATURES helps
> 

I posted a patch for this over at bug 196031. Maybe someone that gets CC'd here
has the power to fix it.