uclibc pthreads debugging troubles with recent tools

[Peter S. Mazinger]

On Fri, 30 Jun 2006, Clem Taylor wrote:

> On 6/30/06, Erik Andersen <andersen at codepoet.org> wrote:
> > On Fri Jun 30, 2006 at 04:31:36PM -0400, Clem Taylor wrote:
> > > It looks like gdb doesn't fully realize that it is debugging a
> > > threaded app,
> >
> > did you happen to strip libthread_db?  If so, that is
> > almost certainly the cause of your grief.

When I rewrote the makefiles about a year ago I have asked about this and 
the answer was:
If pthread debugging is enabled, libpthread.so should not be stripped but 
libthread_db.so can be stripped (the current makefiles do exactly this, 
libthread_db.so is not stripped only if DODEBUG is enabled)

Peter
> 
> This was one of the early things I checked. With my recent uclibc
> version I have NOSTRIP=y set and /lib/libthread_db-0.9.28.so is not
> stripped. Interestingly enough the working system has a stripped
> libthread_db, but libpthread-0.9.28.so has symbols and pthread
> debugging is working just fine.
> 
> Looking at straces of the working and non working gdb, it really looks
> like my new gdb doesn't realize that it is debugging a threaded
> program. Also, in the working case, it seems like gdb only reads the
> first 4096 bytes of /lib/libthread_db.so.1 before the program is run,
> but it doesn't read it once the program is run. However, it does read
> a bunch of /lib/libpthread.so.0, but the broken version doesn't even
> open libpthread.so.0.
> 
> It just seems like gdb doesn't realize it is debugging a threaded app.
> 
>                        Any ideas on things to try?
>                        Clem
> 
> 

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2