This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]