This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC] New command 'gcore'
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