store the contents of target’s RAM in frequent intervals

store the contents of target’s RAM in frequent intervals

[Sandeep222]

Hi,
            I would like to know if there is any possibility for adding
functionality in GDB which could store the contents of target’s RAM in
frequent intervals into hard disk so that, when accidentally switched off or
shut down of an embedded target, we can resume the execution of the program
from where it earlier stopped (i.e previous save point). Conceptually It is
some what similar to the Hibernate function used in Windows xp, Service pack
2. I was thinking of inducing this functionality for embedded targets in
particular. 
           Need araises when a test program is made to run for days and
probably weeks. Suppose, if someone switches off the unit on say 2nd day, it
should be able to continue from that point. Else, the program is made to run
all over again resulting in wastage of time.

Regards, 
Sandeep

-- 
View this message in context: http://www.nabble.com/store-the-contents-of-target%E2%80%99s-RAM-in-frequent-intervals-tp20849726p20849726.html
Sent from the Sourceware - gdb list mailing list archive at Nabble.com.

Re: store the contents of target’s RAM in frequent intervals

[Michael Snyder]

Sandeep222 wrote:
> Hi,
>             I would like to know if there is any possibility for adding
> functionality in GDB which could store the contents of target’s RAM in
> frequent intervals into hard disk so that, when accidentally switched off or
> shut down of an embedded target, we can resume the execution of the program
> from where it earlier stopped (i.e previous save point). Conceptually It is
> some what similar to the Hibernate function used in Windows xp, Service pack
> 2. I was thinking of inducing this functionality for embedded targets in
> particular. 
>            Need araises when a test program is made to run for days and
> probably weeks. Suppose, if someone switches off the unit on say 2nd day, it
> should be able to continue from that point. Else, the program is made to run
> all over again resulting in wastage of time.

Sounds a lot like a checkpoint.  ;-)

GDB has checkpoint functionality for some native operating systems
(eg. Linux), but not at present for remote (embedded) targets.

It would be cool, but potentially expensive, eg. if it involved
downloading the entire contents of target memory.

Some investment in developing a smart debug agent that ran on the
target side might result in the ability to save, eg., just the parts
of memory that have changed since the last checkpoint.

I've also thought about this in terms of generating a target
core file -- which would also involve sucking a bunch of target
memory over to the host, but in this context, we could use
section start/end addresses at least for some of it, and then
we would need to account for stack and heap...

Re: store the contents of target’s RAM in frequent intervals

[Nicholas Mc Guire]

> Sandeep222 wrote:
> > Hi,
> >             I would like to know if there is any possibility for adding
> > functionality in GDB which could store the contents of target’s RAM in
> > frequent intervals into hard disk so that, when accidentally switched off or
> > shut down of an embedded target, we can resume the execution of the program
> > from where it earlier stopped (i.e previous save point). Conceptually It is
> > some what similar to the Hibernate function used in Windows xp, Service pack
> > 2. I was thinking of inducing this functionality for embedded targets in
> > particular.

This sounds like BLCR - Berkely Lab Checkpoint Restart -
http://ftg.lbl.gov/CheckpointRestart/CheckpointRestart.shtml
works very nice on embedded targets especially for errors that dont
reproduce well or take days/weeks to appear. This is implemented as
a set of loadable modules for 2.6 (up to 2.6.26 I think)

This solution is though limited to GNU/Linux - so I dont know if that fits
for you.

hofrat