This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: debugging timer dependent programs thru gdb
- To: rajeev at inablers dot net
- Subject: Re: [ECOS] debugging timer dependent programs thru gdb
- From: Bart Veer <bartv at redhat dot com>
- Date: Wed, 15 Aug 2001 14:26:13 +0100
- Cc: ecos-discuss at sources dot redhat dot com
- References: <200108130937.PAA17815@inablers.net> <3B7809D7.BCDBE408@redhat.com>
- Reply-To: bartv at redhat dot com
>>>>> "Jifl" == Jonathan Larmour <jlarmour@redhat.com> writes:
Jifl> Rajeev wrote:
>>
>> hi,
>> i would like to know if gdb will be able to help me debug
>> time-dependent applications (like multithreading) because i was
>> wondering how the gdb would be able to physically hold the
>> clock to the cpu. Does it have a software emulation of the
>> timers?
Jifl> Nope. When debugging a remote embedded target, in general
Jifl> interrupts are disabled, that's all. If stuff is timer
Jifl> dependent, it will "lose" time.
One extra piece of information: pretty much any form of debugging on
real hardware is going to interfere with real-time responsiveness and
the like. If you have stopped the application on a breakpoint then it
can no longer respond to external events - there are some games that
can be played so that some threads continue running while other
threads are being debugged, but debugging on real hardware is
intrinsicaly intrusive to some extent.
There is a way around this: use architectural simulators. In theory
those allow you to stop the I/O world at the same time as the
processor being simulated, so effectively no time elapses while you
are doing debugging. A good place to look might be the SID project,
http://sources.redhat.com/sid/, although I am not up to date on that
project's current status and how well it deals with accurate I/O
timing.
Bart