Re: [RFC] New command 'gcore'

[Andrew Cagney <ac131313@cygnus.com>]

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