This is the mail archive of the gdb@sourceware.org mailing list for the GDB 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: store the contents of targetâs RAM in fre quent intervals


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


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