Re: [ECOS] Debugging multi-threaded eCos application using GDB

[Bart Veer <bartv@redhat.com>]

>>>>> "Nadine" == Nadine Albiez-extern <Nadine.Albiez-extern@ascom.fr> 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