Re: mi/2414: examine data via gdb/MI fails

Re: mi/2414: examine data via gdb/MI fails

[drow]

Synopsis: examine data via gdb/MI fails

State-Changed-From-To: open->closed
State-Changed-By: drow
State-Changed-When: Tue Feb 26 20:04:51 2008
State-Changed-Why:
    Not a GDB bug.  Thanks for responding.

http://sourceware.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=2414

Re: mi/2414: examine data via gdb/MI fails

[Daniel Jacobowitz]

The following reply was made to PR mi/2414; it has been noted by GNATS.

From: Daniel Jacobowitz <drow@false.org>
To: ullrich.martini@gi-de.com
Cc: gdb-gnats@sources.redhat.com
Subject: Re: mi/2414: examine data via gdb/MI fails
Date: Tue, 19 Feb 2008 08:24:50 -0500

 On Tue, Feb 19, 2008 at 08:46:38AM -0000, ullrich.martini@gi-de.com wrote:
 > 604-data-read-memory 421888 x 1 1 100
 
 This is normally a request for decimal address 421888, unless you or
 Eclipse has been playing with "set radix".
 
 You'd have to send us a complete transcript of the GDB/MI session plus
 any init scripts to be sure.
 
 -- 
 Daniel Jacobowitz
 CodeSourcery

mi/2414: examine data via gdb/MI fails

[ullrich.martini]

>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: