From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6808 invoked by alias); 12 Dec 2001 22:17:09 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 6291 invoked by uid 22784); 12 Dec 2001 22:15:50 -0000 From: Michael Snyder Newsgroups: cygnus.patches.gdb Subject: [RFC] New command 'gcore' Date: Wed, 12 Dec 2001 14:17:00 -0000 Organization: Red Hat, Inc. Message-ID: <3C17D3A0.DE140BFB@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 1008194645 541 205.180.231.12 (12 Dec 2001 22:04:05 GMT) X-Complaints-To: postmaster@cygnus.com NNTP-Posting-Date: 12 Dec 2001 22:04:05 GMT X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2smp i686) X-Accept-Language: en To: gdb-patches@sources.redhat.com DJ-Gateway: from newsgroup cygnus.patches.gdb X-SW-Source: 2001-12/txt/msg00328.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...