From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24158 invoked by alias); 13 Dec 2001 00:46:49 -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 23457 invoked by uid 22784); 13 Dec 2001 00:45:30 -0000 From: Michael Snyder Newsgroups: cygnus.gdb Subject: [RFC] New gdb command 'gcore' Date: Wed, 12 Dec 2001 16:46:00 -0000 Organization: Red Hat, Inc. Message-ID: <3C17E55D.8CDB8F0@cygnus.com> NNTP-Posting-Host: reddwarf.cygnus.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: cronkite.cygnus.com 1008199186 1452 205.180.231.12 (12 Dec 2001 23:19:46 GMT) X-Complaints-To: postmaster@cygnus.com NNTP-Posting-Date: 12 Dec 2001 23:19:46 GMT X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2smp i686) X-Accept-Language: en To: gdb@sources.redhat.com DJ-Gateway: from newsgroup cygnus.gdb X-SW-Source: 2001-12/txt/msg00121.txt.bz2 I would like to discuss adding a new command 'gcore' to gdb. This is at a very early stage, I just want to sound people out about it. The idea is that 'gcore' would cause gdb to generate a core image of the inferior program (just like the 'gcore' unix command). The user could drop a core file at any point in the inferior's execution, and save the memory and register state for debugging later. We ought to be able to cook up an elf core file pretty easily using bfd. This would probably require one or more new target and/or architecture vectors, for instance to get a list of memory regions in use (which would be easy for a /proc target, but might be progressively harder for ptrace, sim, remote...). Some targets may not be able to implement it right away, but in principle it could even be made to work for remote embedded targets. 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...