This is the mail archive of the
mailing list for the GDB project.
Re: [rfc][3/3] Remote core file generation: memory map
Pedro Alves <firstname.lastname@example.org> writes:
> On Wednesday 09 November 2011 18:27:07, Ulrich Weigand wrote:
>> OK. In the meantime, I've noticed the discussion going on in parallel
>> on the "info core mappings" commands. If we implement this, we have
>> the somewhat weird situation that we can show mappings for native
>> processes and for core files, but not for processes attached to remotely,
>> even if the target is also Linux ...
>> It would appear to me that this command actually just needs the very
>> same data I need here for the generate-core-file command, namely the
>> current list of memory mappings.
>> If we create a new target object for VMA memory mappings, maybe we
>> ought to then have a standard "info mappings" (or the like) command
>> implemented in GDB *common code* that works likewise on native,
>> core file, *and* also gdbserver targets; in fact, on all targets
>> that provide that new target object (which may need to be a bit
>> richer, e.g. provide mapped file names as well)?
> Sounds like a good idea indeed.
I totally agree. When doing the `info core' patch, I often found myself
thinking about how `info proc mappings' needed to be reworked.
Anyway, just to be clear, will this new command be implemented
differently than the current `info proc mappings'? I don't know about
you, but cat'ing /proc/PID/maps is something that could be improved.