From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4939 invoked by alias); 5 Dec 2008 19:02:15 -0000 Received: (qmail 4778 invoked by uid 22791); 5 Dec 2008 19:02:14 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.115.85.69) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 05 Dec 2008 19:01:26 +0000 Received: from mailhost5.vmware.com (mailhost5.vmware.com [10.16.68.131]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 7C0FB3030; Fri, 5 Dec 2008 11:01:24 -0800 (PST) Received: from [10.20.92.151] (promb-2s-dhcp151.eng.vmware.com [10.20.92.151]) by mailhost5.vmware.com (Postfix) with ESMTP id 74F59DC0BB; Fri, 5 Dec 2008 11:01:24 -0800 (PST) Message-ID: <493979E2.90707@vmware.com> Date: Fri, 05 Dec 2008 19:02:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Sandeep222 CC: "gdb@sourceware.org" Subject: Re: store the contents of =?UTF-8?B?dGFyZ2V04oCZcyBSQU0gaW4gZnJl?= =?UTF-8?B?cXVlbnQgaW50ZXJ2YWxz?= References: <20849726.post@talk.nabble.com> In-Reply-To: <20849726.post@talk.nabble.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-12/txt/msg00014.txt.bz2 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...