Rui Paulo <rpaulo@NetBSD.org> writes:

> Currently, our gdb is unable to trace/debug pthreaded applications.
> Debugging some application is a task often performed, mainly on a
> operating systems used on researching, such as NetBSD.
> 
> It doesn't matter if the program uses pthread_* calls or not,
> it stops on errors from the pthread shared library. The only way to debug,
> a pthreaded application is by statically link it, which is sub-optimal.
> 
> I plan to take a look at gdb code, but since it's the first time I'm going
> to look at it, I'm not expecting to come up with a fix right now.

The issues here are largely initialization-order ones regarding the
way that the thread target (nbsd-thread.c) decides that an application
is threaded and interposes the thread-aware debugging routines. To
start a program, GDB calls a "start_inferior()" routine. During the
startup, various shared libraries are loaded, and each of those
triggers an event. The nbsd-thread.c watches for the loading of
libpthread to activate things, but getting the point of activation
correct is difficult, since it has to work for all combinations of
static and dynamic linking with starting an inferior process, attaching
to an existing process, and reading a core file. Mixing in the thread
routines too late will result in various spurious traps as the
non-thread-aware code; mixing it in too early will cause problems as
the thread library isn't sufficently initialized to cope with the
libpthread_dbg operations yet.

It's a great ball of wax, lemme tell you.

(Also, it would be nice to use a more modern version of GDB. Versions
after 6.1 require some restructuring of the thread code to adapt to
major changes in the register-fetching interface, which I'm working on
in my Copious Free Time).

        - Nathan