This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC] New command 'gcore'
- From: Jason R Thorpe <thorpej at wasabisystems dot com>
- To: Eli Zaretskii <eliz at is dot elta dot co dot il>
- Cc: msnyder at cygnus dot com, gdb-patches at sources dot redhat dot com
- Date: Wed, 12 Dec 2001 15:28:14 -0800
- Subject: Re: [RFC] New command 'gcore'
- Organization: Wasabi Systems, Inc.
- References: <3C17D3A0.DE140BFB@cygnus.com> <5567-Thu13Dec2001010400+0200-eliz@is.elta.co.il>
- Reply-to: thorpej at wasabisystems dot com
On Thu, Dec 13, 2001 at 01:04:00AM +0200, Eli Zaretskii wrote:
> > From: Michael Snyder <msnyder@cygnus.com>
> > Newsgroups: cygnus.patches.gdb
> > Date: Wed, 12 Dec 2001 14:01:04 -0800
> >
> > 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.
>
> Sounds great!
Yah, gcore is cool, but it generally requires support from the kernel
in one way or another:
* You need to know which chunks of the address space are
actually mapped, and the protection of those regions.
* You need to know if a given chunk of the address space
should be dumped, even if it is mapped (consider a
memory-mapped device where reads produce side-effects).
* You need to know how many LWPs there are, and need to
be able to iterate over them.
--
-- Jason R. Thorpe <thorpej@wasabisystems.com>