Addition of a special memory reading command

Addition of a special memory reading command

[Tomas Martinec]

Hello,

I am developing an Eclipse plugin for my virtual machine and I have
encountered some problems with displaying memory of the debuggee.
Address space of my debuggee can contain holes (which are not page
aligned and generally can have any size) and reading such a memory
causes troubles. For example, lets consider that the memory at
addresses 0x10000000-0x10000004 is valid and the neighbourhood is not
valid. Then gdb that is ordered to read 20 bytes of memory from
address 0x0ffffff0 will not show the last valid bytes.
So, if the programmer (or the gdb frontend) wants to get the real
memory contents in this case, he must read the memory for each
interested address until he find a valid memory block.

I can understand that my case is rather special, but it can happen in
usual C userspace application too. If the memory page at address
0x0010000 is mapped and the previous one is not mapped, reading 100
bytes from the address 0x000fffff fails. This issue can be illustrated
on the following source code:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/mman.h>

int main(void) {
	void* address = (void*) 0x00100000;

	char* allocated_address = (char*) mmap(address,
			4092,
			PROT_READ | PROT_WRITE,
			MAP_FIXED | MAP_PRIVATE | MAP_ANONYMOUS,
			-1,
			0
			);

	strcpy(allocated_address, "testing string");
	return EXIT_SUCCESS;
}

I think that having a special memory command would solve this. The
command would ask the virtual machine about the next valid block of
memory from the provided address. If the programmer encounters "Cannot
access memory at address ..." during examining the memory, he can use
the proposed command to ensure that the memory really is not valid or
to find out that the valid memory begins from an address X. My VM can
provide such information to gdb and, for the userspace scenario, I can
imagine that an operating system would be able to get the info from
page tables.

Probably I will be able to write a patch to gdb that implements the
command. The patch would create the command and implement it in the
remote protocol - for other targets it would just print "not
supported". However, I doubt that the Eclipse CDT community would
accept changes related to the proposed command until the command is
accepted into gdb. And keeping the patches for both gdb and CDT does
not seem to be fortunate to me.

So, how do you like the proposed command? Might it be possible to
integrate it to the future version of gdb?

Regards,
Tomas

Re: Addition of a special memory reading command

[Petr Hluzín]

Hi Tomas

On 30 May 2011 18:04, Tomas Martinec <fyzmat@gmail.com> wrote:
>
> Probably I will be able to write a patch to gdb that implements the
> command. The patch would create the command and implement it in the
> remote protocol - for other targets it would just print "not
> supported".

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

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.

-- 
Petr Hluzin

Re: Addition of a special memory reading command

[Tomas Martinec]

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

Re: Addition of a special memory reading command

[Petr Hluzín]

On 1 June 2011 18:35, Tomas Martinec <fyzmat@gmail.com> wrote:
> 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.

Are you aware GDB remote protocol can debug multiple processes at the same time?
Separate processes may be more appropriate if the addressing modes are
very different - which I do not know.

>
> Would you accept this improvement?

Someone else has to answer this. I am just a regular observer here,
not a developer or a maintainer.

-- 
Petr Hluzin

Re: Addition of a special memory reading command

[Tomas Martinec]

>> 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.
>
> Are you aware GDB remote protocol can debug multiple processes at the same time?
> Separate processes may be more appropriate if the addressing modes are
> very different - which I do not know.

You mean representing processors as processes? Well, that might be
realizable in gdb. But I am afraid that it would cause a lot of
troubles in eclipse. For example, eclipse launch a separate gdb
session for each debugged process.

Tomas

Re: Addition of a special memory reading command

[Tomas Martinec]

Hello,

>> Would you accept this improvement?
>
> Someone else has to answer this. I am just a regular observer here,
> not a developer or a maintainer.

is there anybody who can discuss the extension of memory map command?

Tomas