Re: Addition of a special memory reading command

[Tomas Martinec <fyzmat@gmail.com>]

Hello,

thanks for guide.

> Also there are "info proc mappings" not "info target", unfortunately
> neither these are  exactly what you want.

> I guess it would be useful to enhance these commands than implementing new ones.

The information about memory mapping would definitely help to solve my
issue. I was wondering whether the size of transfered information
between gdb and eclipse would be too large with comparison to my
proposed command. Eclipse would use the mapping command just when
normal memory read command fails. That probably will not happen very
often, so the size of transfered data should not matter. So I think
that sending the whole memory map to the eclipse is not a bad idea.

The "info proc mappings" command seems to be currently implemented in
procfs.c and linux-nat.c modules. The both implementations show: start
address, end address, size and offset. Additionally the procfs.c
implementation shows flags and the linux-nat.c implementation object
filename. The shown offset and object columns does not have any
meaning for my VM scenario. So the "info proc mappings" would show
always "start address", "end address/size" and optionally some other
columns.

Currently the "info proc mappings" seems to be available only when gdb
is compiled for proper platform. I would make it available always,
because it could be used for remote targets. Calling the command would
choose which implementation (remote/linux/procfs) would be done.

> GDB remote protocol already allows specifying some memory regions,
> though you cannot specify a unreadable&unwritable "hole". The remote/Memory-Map-Format.html
> command seems to be accesible as "info mem" command. See
> http://sourceware.org/gdb/onlinedocs/gdb/Memory-Map-Format.html

The command "qXfer:memory-map:read" looks suitable for getting the
memory map from a remote target, thanks for pointing it out.

The cli form of the "info proc mappings" command is not very suitable
for the frontend. Maybe creating an MI equivalent to the "info proc
mappings" would be nice. The MI form also enables me to specify the
thread. That is needed in my VM scenario, because I represent
processors as threads and each processor can be in different
addressing mode.

Would you accept this improvement?

Tomas