[RFC] New command 'gcore'

[RFC] New command 'gcore'

[Michael Snyder]

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...

Re: [RFC] New command 'gcore'

[Eli Zaretskii]

> 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!

Re: [RFC] New command 'gcore'

[Jason R Thorpe]

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>

Re: [RFC] New command 'gcore'

[Kevin Buettner]

On Dec 12,  2:01pm, Michael Snyder wrote:

> 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).

I have no problem with the concept, but I'm wondering if we might not
think of a better name for this new command.

Kevin

Re: [RFC] New command 'gcore'

[Andrew Cagney]

Cool feature of the month comes to mind.  Once this is working all sorts of things are possible.


> 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.


ac131313@nettle$ cat /proc/$$/maps
01800000-01880000 r-xp 00000000 0a:05 10177
018b0000-018c5000 rwxp 00070000 0a:05 10177
018c5000-018e7000 rwxp 00000000 00:00 0
418b0000-418c5000 rwxp 00000000 0a:05 93269
418c5000-418c8000 rwxp 00000000 00:00 0
418c8000-418d0000 rw-p 00000000 00:00 0
418d0000-418d2000 r-xp 00000000 0a:05 87796
41911000-41913000 rwxp 00001000 0a:05 87796
41913000-419a6000 r-xp 00000000 0a:05 87369
419e5000-419f2000 rwxp 00092000 0a:05 87369
419f2000-419ff000 rwxp 00000000 00:00 0
7dfff000-7fdff000 ---p 00000000 00:00 0
7fdff000-7fff0000 rwxp 00000000 00:00 0
7fff0000-7ffff000 rwxp 00000000 00:00 0

The wonders of procfs!


More seriously, the target vector would need an enhancement to include 
an address spaces iterator.


> 	* 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).


That one is more interesting.  I suspect it might be best to punt this 
and leave finding the solution to those with the problem :-)

I would note that there is now a memory attribute framework so GDB might 
be able to extract some of the information from that.  A remote target 
might use a remote query (or just suck the memory it knows is relevant). 
  However, if I were Michael, I'd just get a basic proof of concept done.


> 	* You need to know how many LWPs there are, and need to
> 	  be able to iterate over them.


Hmm. Yes, good point.

To be more exact.  On a target such as Solaris where there is an N:M 
relationship between (N) threads and (M) LWPs, a LWP iterator would be 
needed.

Andrew

Re: [RFC] New command 'gcore'

[Jason R Thorpe]

On Wed, Dec 12, 2001 at 05:17:02PM -0800, Andrew Cagney wrote:

 > > 	* 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).
 > 
 > 
 > That one is more interesting.  I suspect it might be best to punt this 
 > and leave finding the solution to those with the problem :-)

Eh, I guess.  But most Unix systems explcitly skip memory regions that
aren't file-backed or anonymous pages, so GDB should skip such regions,
too.

 > To be more exact.  On a target such as Solaris where there is an N:M 
 > relationship between (N) threads and (M) LWPs, a LWP iterator would be 
 > needed.

You don't really need a thread->lwp mapping.  You just need to know
how many LWPs there are, and what their lwpids are (so you can fetch
their registers and also properly mark the note in the core file with
the lwpid).  Presumably, the thread->lwp mapping would be contained
in the memory image somewhere (e.g. the thread library's scheduler
data structures).

Actually, another interesting problem... you need to deal with the lazy
FP context switching that many Unix systems do, as well.  E.g. when a
process runs, even if it has previously used the FPU, it may be running
on a processor which is different from the last processor it ran on,
which means its FPU state could be somewhere else (that is, in another
processor's FP registers, NOT in the process's PCB or in the current
processor's FP registers), so you need to figure out some way to deal with
that, as well.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

Re: [RFC] New command 'gcore'

[Andrew Cagney]

> To be more exact.  On a target such as Solaris where there is an N:M 
>  > relationship between (N) threads and (M) LWPs, a LWP iterator would be 
>  > needed.
> 
> You don't really need a thread->lwp mapping.  You just need to know
> how many LWPs there are, and what their lwpids are (so you can fetch
> their registers and also properly mark the note in the core file with
> the lwpid).  Presumably, the thread->lwp mapping would be contained
> in the memory image somewhere (e.g. the thread library's scheduler
> data structures).


Yes, sorry, I didn't quite say it right.  For solaris, GDB presents 
threads to the user.  Underneath the hood, GDB uses lib thread DB to map 
between LWPs and threads.  GDB, here, needs to put the LWP state into 
the core file.  Not the thread state.


> Actually, another interesting problem... you need to deal with the lazy
> FP context switching that many Unix systems do, as well.  E.g. when a
> process runs, even if it has previously used the FPU, it may be running
> on a processor which is different from the last processor it ran on,
> which means its FPU state could be somewhere else (that is, in another
> processor's FP registers, NOT in the process's PCB or in the current
> processor's FP registers), so you need to figure out some way to deal with
> that, as well.


But is that GDB's problem?  If the procfs / ptrace / ttrace interface is 
lieing (returning fp registers for the wrong LWP/thread) then we've 
worse problems than the above :-)

enjoy,
Andrew

Re: [RFC] New command 'gcore'

[Jason R Thorpe]

On Wed, Dec 12, 2001 at 05:48:03PM -0800, Andrew Cagney wrote:

 > But is that GDB's problem?  If the procfs / ptrace / ttrace interface is 
 > lieing (returning fp registers for the wrong LWP/thread) then we've 
 > worse problems than the above :-)

I suppose it all depends on what interface the backend uses to extract
the info from the target.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

Re: [RFC] New command 'gcore'

[Andrew Cagney]

> On Wed, Dec 12, 2001 at 05:48:03PM -0800, Andrew Cagney wrote:
> 
>  > But is that GDB's problem?  If the procfs / ptrace / ttrace interface is 
>  > lieing (returning fp registers for the wrong LWP/thread) then we've 
>  > worse problems than the above :-)
> 
> I suppose it all depends on what interface the backend uses to extract
> the info from the target.


GDB's thread code is implemented as (loosely speaking):

	thread model
	-> thread db library
	-> LWP / linux process / ... interface

VS handling a core file:

	thread model
	-> thread db library
	-> core file interface

provided the core file contains the same information as would have been 
returned by the LWP / linux process / ... interface, it should all be 
fine ......

i think,
Andrew

Re: [RFC] New command 'gcore'

[Michael Snyder]

Kevin Buettner wrote:
> 
> On Dec 12,  2:01pm, Michael Snyder wrote:
> 
> > 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).
> 
> I have no problem with the concept, but I'm wondering if we might not
> think of a better name for this new command.

I'm open, of course -- I just thought that the name "gcore" already
exists, and pretty much describes the desired functionality.

Well, for now, I'll just think of 'gcore' as the 'code name' for it.
A la "ginger".  ;-)

Re: [RFC] New command 'gcore'

[Michael Snyder]

Kevin Buettner wrote:
> 
> On Dec 12,  2:01pm, Michael Snyder wrote:
> 
> > 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).
> 
> I have no problem with the concept, but I'm wondering if we might not
> think of a better name for this new command.

OK -- what would you suggest as a better name?
I picked "gcore" because there is an analogous unix command
on some systems that does approximately what I am trying to
do here -- drop a core file from a running process.