This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: run-mode debugging with eCos and GDB?


Chris Wein wrote:

I am evaluating RTOS' for a new project and am coming from a commercial RTOS
background (VxWorks, ThreadX) where those systems offered what is known as
run-mode debug.  In this mode, a specific thread is the focus on the
debugging activity and a breakpoint in that thread suspends the thread while
leaving all other threads running.  This mode contrasts with halt-mode
debugging where a breakpoint halts the entire processor and therefore all
threads stop.  Run-mode debugging is extremely useful/necessary for
development where we are managing external activities that cannot be stopped
(such as software flow control of incoming data streams).

eCos is a contender for this new project but it is not clear to me if
"thread awareness" of GDB with eCos means that ability to display thread
specific information AND is also equivalent to run-mode debugging, or it is
merely the display of thread information.  The bottom line is, when
debugging in eCos and GDB do all application tasks suspend or merely the
targeted thread?

All threads are suspended and redboot or the jtag/bdm/ice has full control of the CPU.


Introducing this type of debugging would mean a distinct change in the way eCos works since this model assumes that there is a distinct seperation between application and kernel where threads can be frozen/thawed for debugging. With eCos, there is no such seperation. Application and kernel are linked together.

Also, there is a question as to exactly how useful this type of debug mode will be in eCos since it assumes the threads that continue running are not dependant on any resources that are locked by the thread being debugged. For example, debugging eCos applications currently allows you to step through the eCos "kernel", including stepping through critical regions such as the scheduler. If you were to single step or break a thread in the kernel when the scheduler were locked, no other threads would be able to run anyway.

HTH

-- Alex




Thanks







-- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]