From mboxrd@z Thu Jan  1 00:00:00 1970
From: Bart Veer <bartv@cygnus.co.uk>
To: jlarmour@cygnus.co.uk
Cc: lunn@ma.tech.ascom.ch, ecos-discuss@sourceware.cygnus.com
Subject: [ECOS] Re: info threads on Synthetic target
Date: Fri, 24 Sep 1999 10:16:00 -0000
Message-id: <199909241713.SAA04024@sheesh.cygnus.co.uk>
References: <199909241450.QAA01842@biferten.ma.tech.ascom.ch> <37EB9802.C5C795B7@cygnus.co.uk>
X-SW-Source: 1999-09/msg00034.html

>>>>> "Jifl" == Jonathan Larmour <jlarmour@cygnus.co.uk> writes:

    >> For the Synthetic linux target, is gdb supposed to be able to
    >> see the threads? The "info threads" command does not work. I
    >> have the HAL option CYGDBG_HAL_DEBUG_GDB_THREAD_SUPPORT
    >> enabled.

    Jifl> Simple answer: nope. It would require gdb support to be
    Jifl> added I'm afraid.

Or for a more complete explanation (although be warned that I am not a
gdb expert)...

On embedded targets such as an evaluation board, gdb typically works
by interacting with gdb stub code on the target via a serial line.
With eCos we have control over the gdb stubs, so they know how eCos
threads work and can send back the right data in response to the
relevant gdb packets.

For the synthetic target there are no target-side stubs involved.
Instead gdb will use exactly the same debugging techniques that it
would use for a native Linux application, i.e. the ptrace() system
call or something along those lines. For gdb to provide thread-aware
debugging in these circumstances, it would need to know about eCos
kernel data structures so that it can peek around the synthetic target
address space. This is not impossible (although implementing it
cleanly is non-trivial), but the work has not yet been done.

Bart Veer // eCos net maintainer