remotely debugging muti-threaded applicaton did not work with gdb 6.3.50.20050725-cvs

[Michael Zhang]

Thanks all,

I will try 6.6 and keep you posted.

Cheers,

Michael

On 5/29/07, Michael Snyder <Michael.Snyder@access-company.com> wrote:
>
>
>
> Most likely your target is configured to use the new NPTL threads.
>  GDB 6.3 is quite good at handling NPTL threads, but unfortunately,
>  gdbserver 6.3 isn't.
>
>  If you can upgrade to GDB 6.6, that would be best.
>
>  At a minimum, you need to build the gdbserver from version 6.6
>  and install it on your target.
>
>  Michael
>
>
>
>  -----Original Message-----
>  From: gdb-owner@sourceware.org on behalf of Michael Zhang
>  Sent: Tue 5/29/2007 9:13 AM
>  To: gdb@sourceware.org
>  Subject: remotely debugging muti-threaded applicaton did not work with gdb
> 6.3.50.20050725-cvs
>
>  Hi there,
>
>   I have been battling with this problem for a week now and searched
>  all the available information ( GDB manual, gdb mailing list, etc.)
>  but unfortunately could not find an answer. Here is my setup.
>
>   - Host : x86 running FC1 with linux 2.4.22-1.2115.nptl
>   - Target : mips le running linux 2.4.17
>   - gdb 6.3.50.20050725-cvs and its included gdbserver (all cross-built
>  for mips processor)
>   - libc library 2.2.3 ( most of the shared library bear this version )
>
>   Debugging problem:
>
>   The gdb on the host can talk to the gdbserver on the target and I did
>  not forget to set "solib-absolute-prefix". If I set breakpoints before
>  the multiple threads are spawned, I could step through the code when
>  the breakpoint was hit. However, once the application finished
>  creating threads and if I stop the program to step through, it won't
>  step and alway stuck in libc.so.6. The worst is all the threads are
>  getting killed. And "info threads" never returns anything just
>  reporting that the gdbserver could not get thread list.
>
>   Any ideas even though it might have bee asked before. I am basically
>  at my wit's end.
>
>   Cheers,
>
>   Michael
>
>