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]

Re: debugging timer dependent programs thru gdb


>>>>> "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


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