Re: [rfc][3/3] Remote core file generation: memory map

[Sergio Durigan Junior <sergiodj@redhat.com>]

Pedro Alves <pedro@codesourcery.com> 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.

Thanks.