From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1484 invoked by alias); 19 Feb 2008 08:48:03 -0000 Received: (qmail 1468 invoked by uid 71); 19 Feb 2008 08:48:02 -0000 Resent-Date: 19 Feb 2008 08:48:02 -0000 Resent-Message-ID: <20080219084802.1467.qmail@sourceware.org> Resent-From: gdb-gnats@sources.redhat.com (GNATS Filer) Resent-To: nobody@sources.redhat.com Resent-Cc: gdb-prs@sources.redhat.com Resent-Reply-To: gdb-gnats@sources.redhat.com, ullrich.martini@gi-de.com Received: (qmail 1172 invoked by uid 48); 19 Feb 2008 08:46:38 -0000 Message-Id: <20080219084638.1171.qmail@sourceware.org> Date: Tue, 19 Feb 2008 08:48:00 -0000 From: ullrich.martini@gi-de.com Reply-To: ullrich.martini@gi-de.com To: gdb-gnats@sources.redhat.com X-Send-Pr-Version: gnatsweb-2.9.3 (1.1.1.1.2.31) Subject: mi/2414: examine data via gdb/MI fails Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org X-SW-Source: 2008-q1/txt/msg00040.txt.bz2 >Number: 2414 >Category: mi >Synopsis: examine data via gdb/MI fails >Confidential: no >Severity: non-critical >Priority: medium >Responsible: unassigned >State: open >Class: change-request >Submitter-Id: net >Arrival-Date: Tue Feb 19 08:48:01 UTC 2008 >Closed-Date: >Last-Modified: >Originator: ullrich.martini@gi-de.com >Release: 6.5.50.20060612-cvs >Organization: >Environment: windows xp native >Description: This bug report describes a misunderstanding between gdb and eclipse. I do not know where the fault is, therefore I send it to eclipse and gdb. I am experiencing the following problem when using eclipse and gdb via JTAG to a remote target: I can connect, start, stop, step, set breakpoints, inspect variables. However, I cannot examine the contents of a pointer via the variables or memory window. In the gdb console it looks like the following output generated by Eclipse when I tried to open the memory dump window and look at the memory area starting at address 0x67000: 604-data-read-memory 421888 x 1 1 100 604^done,addr="0x00421888",nr-bytes="100",total-bytes="100",next-row="0x004218ec",prev-row="0x00421824",next-page="0x004218ec",prev-page="0x00421824",memory=[{addr="0x00421888",data=["0xff" <...more 0xff following >]}] (gdb) 605-data-read-memory 421568 x 1 1 736 605^done,addr="0x00421568",nr-bytes="736",total-bytes="736",next-row="0x00421848",prev-row="0x00421288",next-page="0x00421848",prev-page="0x00421288",memory=[{addr="0x00421568",data=["0xff" <...more 0xff following >]}] 421888=0x67000. It seems that eclipse or cdt converts the adress into decimal format, but gdb interprets it as hexadecimal even although the '0x' prefix is not there. If I look at the data at the adress as a sting (e.g. via the variable windows, the contents will be displayed correctly, but in ASCII and quite unreadable) Thus, one could argue that this is a gdb issue. As I suggest in the Fix section below, one solution would be to simply describe this behaviour in the documentaion. Indeed, I think that eclipse ought to emit hex addresses. Could you please confirm to me that this should be considered as eclipse's fault? I am using Eclipse Version: 3.3.1.1 Build id: M20071023-1652 and the Zylin embedded cdt plugin 4.1.14 and gdb 6.5.50.20060612-cvs from yagarto on windows -x P.S.: I have submitted this via email before, but it didn't show up in the database. Therefore I believe that that the submission failed and I resubmit it through the web form. >How-To-Repeat: start a remote debug session, send a read memory command like 604-data-read-memory 421888 x 1 1 100 where the adress would be correct if interpreted as decimal Will be interpreted as hex adresses which is not what eclipse expects >Fix: - throw an error if memory address without 0x prefix is supplied - then it's an eclipse problem - describe this behaviour in the documentation (e.g. "addresses are interpreted as hex even in the absence of the 0x prefix) >Release-Note: >Audit-Trail: >Unformatted: