From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9424 invoked by alias); 14 Dec 2001 14:18:32 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 9403 invoked from network); 14 Dec 2001 14:18:30 -0000 Received: from unknown (HELO harvester.transas.com) (193.125.200.2) by sources.redhat.com with SMTP; 14 Dec 2001 14:18:30 -0000 Received: from localhost (localhost [127.0.0.1]) by harvester.transas.com (Postfix) with SMTP id 489B46B822; Fri, 14 Dec 2001 17:18:29 +0300 (MSK) Received: from clue.transas.com (clue.transas.com [10.0.0.42]) by harvester.transas.com (Postfix) with ESMTP id AC27A6B81F; Fri, 14 Dec 2001 17:18:28 +0300 (MSK) Received: by clue.transas.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Dec 2001 17:18:28 +0300 Message-ID: <2E74F312D6980D459F3A05492BA40F8D5A88DD@clue.transas.com> From: Andrew Volkov To: James Cownie Cc: gdb@sources.redhat.com Subject: RE: [RFC] New gdb command 'gcore' Date: Fri, 14 Dec 2001 06:18:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="koi8-r" X-SW-Source: 2001-12/txt/msg00130.txt.bz2 > > > The holy grail, of course, would be to then give gdb the ability to > > restart the process from the core file state. That would give us a > > checkpoint-and-restart capability that very few debuggers have ever > > had. But that's down the line... > > Unfortunately in general a normal core file does not contain enough > information to allow a process to be restarted, since it doesn't > contain a lot of the information in the kernel which forms part of the > process' state. > > There are many "fun" issues which arise when trying to implement > checkpointing, such as > > 1) Open files. What fds ar open ? What's the seek position of each ? > What about pipes ? > > 2) process id; does it change between the original process and its > reincarnation ?) > > 3) parent process id (same question). > > 4) relationship with child processes (if any). Do you checkpoint the > whole process group ? > > 5) network connections. Can you reconstruct them ? What about the > state of the other end ? > > 6) time. When the process is reincarnated does it see time passing > while it was only a checkpoint ? > > 7) signal handling state. What signal handlers are set up ? What > signals are blocked ? > > 8) State of any timers. Suppose a thread was in a sleep() when should > the sleep complete ? > > 9) State of other potentially long system calls. A listen(), for > instance, or a read from something which isn't ready. > > 10) All the other things which didn't come to mind in the > three minutes > it's taken to type this. > > Of course it's possible to add restrictions to the state a process > must be in before it can be checkpointed, unfortunately if you want to > do the checkpoint from gdb it's going to be hard to know if the > restrictions are valid, since you can arbitrarily invoke gcore between > any two machine instructions. > > It's a nice idea, but I think it's hard :-( (and to do it portably is > _very_ hard). All this problems correct for remoute/native debugging, but how about implementing this in sim? I think this will useful for embeded programming. Andrey Volkov