From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23997 invoked by alias); 13 Dec 2005 19:58:33 -0000 Received: (qmail 23989 invoked by uid 22791); 13 Dec 2005 19:58:32 -0000 X-Spam-Check-By: sourceware.org Received: from wproxy.gmail.com (HELO wproxy.gmail.com) (64.233.184.199) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 13 Dec 2005 19:58:31 +0000 Received: by wproxy.gmail.com with SMTP id 69so1679076wra for ; Tue, 13 Dec 2005 11:58:29 -0800 (PST) Received: by 10.54.72.12 with SMTP id u12mr1545606wra; Tue, 13 Dec 2005 11:58:25 -0800 (PST) Received: by 10.54.102.10 with HTTP; Tue, 13 Dec 2005 11:58:25 -0800 (PST) Message-ID: <4dd65b150512131158q694022c1kba1a5d12f76a3df0@mail.gmail.com> Date: Tue, 13 Dec 2005 19:58:00 -0000 From: Prateek Saxena To: greg@bronevetsky.com Subject: RE: Checkpoint-restart with different code Cc: gdb@sources.redhat.com, drow@false.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2005-12/txt/msg00146.txt.bz2 Hi, I have a stable kernel patch for Linux 2.6.14.3 and Linux 2.4.31 that allows a process to mmap any region of the tracee's process address space, through the /proc/[pid]/mem file. It allows the debugger/tracer to write/read change all parts of the program memory of traced process. You could you this interface to modify the code memory being read by the traced process, by simply mmaping the code/stack/data page in the checkpointer's memory, and writing to it. I have tested some large tracer's with this, and the fsx testsuite. The patches should be available for download in the next week or so. I can send the link as soon as I upload them. -- Prateek Saxena Department of Computer Science, Stony Brook University. Greg Bronevetsky wrote: > I see that there's been some discussion on this list on checkpointing tec= hniques > that may be included in gdb. My research group at Cornell is work= ing on a >number of such checkpointers for both sequential and parallel pro= grams and we >recently decided to try a more challenging variant of checkpo= inting where the >user can take a checkpoint of their program, modify their= source code a bit (add >remove stack variables, move function calls around= a bit and a few other things) >and then resume computation using the modif= ied code. This seems to be very >useful for debugging long-running applicat= ions since the user would be able to >work around the bug without losing a = week's or month's worth of results. (can >happen in high-performance comput= ing) Similarly, its useful for situations where >your execution is in some = particularly buggy corner case and you want to keep >making modifications a= nd trying them out without having to guide the program's >execution back in= to that corner case after every code change. >My question is, has anybody heard of anything that can do this? Obviously, this >kind of checkpointing would require compiler support, so gdb wouldn't have done >this, but have you heard of any systems/research that has addressed this >question? Thanks. >-- >Greg Bronevetsky >490 Rhodes Hall