From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bart Veer To: Nadine.Albiez-extern@ascom.fr Cc: ecos-discuss@sources.redhat.com Subject: Re: [ECOS] Debugging multi-threaded eCos application using GDB Date: Mon, 23 Apr 2001 05:52:00 -0000 Message-id: <200104231252.f3NCq9A30530@sheesh.cambridge.redhat.com> References: X-SW-Source: 2001-04/msg00304.html >>>>> "Nadine" == Nadine Albiez-extern writes: Nadine> Hello, Nadine> I have a question about debugging an eCos multi-threaded Nadine> application using gdb. When I want to see the list of my Nadine> threads , the command "info threads" returns nothing Nadine> (gdb) info threads Nadine> (gdb) thread 1 Nadine> Thread ID 1 not known. Use the "info threads" command to Nadine> see the IDs of currently known threads. Nadine> What can I do for enabling the multi-threaded ? When I use Nadine> a linux test application I have no problem, "info threads" Nadine> returns the list of threads..... Is there any option when Nadine> generating the eCos kernel to allow Gdb to see the eCos's Nadine> Thread (cyg_thread_create)? I observe the same behavior Nadine> with the example program "two_threaded". Is there a Nadine> package to add to ecos.ecc? I use eCos version 1.4.8. , Nadine> gdb version 4.18 (I try gdb 5.0 with the same result) and Nadine> work on a linux target . Thread-aware debugging is not available on all targets, and unfortunately that includes the synthetic target which I assume you are referring to. The problem is with the current implementation of thread-aware debugging. It expects to be able to interact with some code inside the embedded target, for example RedBoot or gdb stubs, that knows about the specific thread implementation being used. Debugging the synthetic target does not involve interacting with remote stubs, instead it uses facilities provided by the system such as ptrace(). To confuse things further, gdb might think that you are trying to debug a multi-threaded Linux application where the threading is provided by Linux. This does not work either: synthetic target threads are not built on top of Linux threads, you want the eCos semantics rather than the Linux ones. We do have some ideas on how to fix this properly, basically making the thread-aware debugging inside gdb much more flexible, but so far nobody has been willing to contribute or fund any of the work involved. Bart