From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4347 invoked by alias); 1 Jun 2011 16:35:21 -0000 Received: (qmail 4269 invoked by uid 22791); 1 Jun 2011 16:35:19 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-qy0-f169.google.com (HELO mail-qy0-f169.google.com) (209.85.216.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 01 Jun 2011 16:35:05 +0000 Received: by qyk2 with SMTP id 2so2389471qyk.0 for ; Wed, 01 Jun 2011 09:35:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.114.77 with SMTP id d13mr5312080qcq.219.1306946104363; Wed, 01 Jun 2011 09:35:04 -0700 (PDT) Received: by 10.229.251.17 with HTTP; Wed, 1 Jun 2011 09:35:04 -0700 (PDT) In-Reply-To: References: Date: Wed, 01 Jun 2011 16:35:00 -0000 Message-ID: Subject: Re: Addition of a special memory reading command From: Tomas Martinec To: =?ISO-8859-1?Q?Petr_Hluz=EDn?= Cc: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-06/txt/msg00003.txt.bz2 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