Re: GDB, pthreads, and kernel threads

[John Clark <jclark@metricsystems.com>]

Robert Hancock wrote:

> John Clark wrote:
>
>> I built the latest GDB-6.3, as well as rebuilt glibc-2.3.5, and now 
>> when I step through the
>> main code line, which creates the tasks (I'm using the pthreads.c 
>> from the GDB testsuite), I do
>> not getany output from:
>>
>> info threads
>>
>> When I set a break point on the entry point of one of the 
>> soon-to-be-created threads,
>> I get a diagnostic message:
>>
>> Program terminated with signal SIGTRAP, Trace/Breakpoint trap.
>> The program no longer exists.
>
>
> Are you sure your glibc and gdb were both configured to support 
> threads when they were compiled?


The application that I'm working with 'works', in the sense that when I 
do a 'ps' there are several processes
listed under the app name, corresponding to the created threads.

When I run gdb with the app, it does load /lib/libthread_db.so.1, so my 
presumption here is that gdb has
been thread enabled.

Since the app is pretty portable, and I've been using NetBSD to develop 
co-develop it, I can run gdb
on the NetBSD side, and 'things' seem to work better. There are still 
some wyrd operational issues
on the NetBSD, but at least when I set a break point in a thread, it 
works, and when I do a
'info threads' command to gdb, it gives a reasonable out put of the list 
of threads. Since the NetBSD
implementation of threads is 'new' to the kernel, I do expect some problems.

Now, because the thread implementation is different between NetBSD and 
Linux, and it seems that Linux
creates distinct 'processes' for the threads, I'm wondering if I have 
not correctly configured my kernel,
or if there is something special one has to do to allow gdb to write to 
one of the created thread processes.

Also, I do believe I'm using the NPTL package for threads. Is there a 
way to absolutely tell without
question?

Thanks
John Clark