[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-debug-dev] Memory Window Hex/ASCII Renderer
|
Hi -
The current behavior of the HEX and ASCII rendering is working as designed.
They are designed to display memory as raw storage and as a result they do
not understand endianess. This has been the behavior expected by our
users.
The renderings provided by the debug platform is to allow debug adapters to
easily take advantage of the Memory View for showing their memory monitors.
Models are not tied to a specific type of renderings and have the freedom
to create customized renderings.
As you can see in this case, developers from different environment expect
different behavior from the same rendering. I think this will be an ideal
example where we can make use of the flexibility in the Memory View and
create your own renderings for your needs. If you need help in this area,
please let me know.
Thanks...
Samantha
"Mikhail
Khodjaiants"
<mikhailk@xxxxxxx To
> "CDT Debug developers list"
Sent by: <cdt-debug-dev@xxxxxxxxxxx>
cdt-debug-dev-bou cc
nces@xxxxxxxxxxx
Subject
Re: [cdt-debug-dev] Memory Window
11/16/2005 11:47 Hex/ASCII Renderer
AM
Please respond to
CDT Debug
developers list
>To me it's the job of the debugger to perform conversion (using the
>"fmt" flag of -data-list-register-values MI command or the "wort-format"
>flag of -data-read-memory) not to Eclipse.
I agree that we should get the formated values from the backend (that was
the original idea).
But it doesn't fit well to the current Memory view model. And the editing
of
the memory would be very costly.
----- Original Message -----
From: "Denis PILAT" <denis.pilat@xxxxxx>
To: "CDT Debug developers list" <cdt-debug-dev@xxxxxxxxxxx>
Sent: Wednesday, November 16, 2005 3:25 AM
Subject: Re: [cdt-debug-dev] Memory Window Hex/ASCII Renderer
Hi all,
I noticed this problem/behaviour in other part of Eclipse like the
register view who performs its own formatting without taking care of
register size but only register type, assuming that type of the debbuged
processor is the same as type of the machine which run Eclipse.
It seems that Eclipse get the value from the debugger only once using
the appropriate MI commands (-data-read-memory or
-data-list-register-values) , and then performs conversion (to integer,
hexa ...) by its own, without asking to the debugger so without taking
care of register size, MAU or any specific processor stuffs.
To me it's the job of the debugger to perform conversion (using the
"fmt" flag of -data-list-register-values MI command or the "wort-format"
flag of -data-read-memory) not to Eclipse.
I already logged a bug
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=88058) but dont know the
status for CDT3.x
Denis
Chuong, Patrick wrote:
> Hi All,
>
> I am seeing something inconsistencies in the memory window, the
> behavior between hex/ascii and integer renderer is somewhat different.
> The first thing that I notice is that in hex/ascii renderer, it is
> showing the value in big endian format even thought the target is
> little endian. But for the unsinged integer renderer, it does consider
> target endianess and set the default display format from the target.
> The second thing that I notice is that when you write to the target in
> hex/ascii renderer, it is writing it in big endian format, which
> doesn?t work for little endian target; the byte order is reversed.
>
> Here is an example, I have a little endian target and have the hex
> renderer displaying memory at address 0, and an unsigned integer
> renderer displaying memory at address 0 as well. And the value at this
> address is 1. The unsigned renderer is displaying 1, but the hex
> renderer is displaying 01000000. When I enter the value 1 in the hex
> renderer, it is displaying 16777216 in the unsigned renderer. I think
> this is an incorrect behavior, I would expect to see 1 in the hex
> renderer (if it consider endianness) and 1 in the unsigned renderer,
> as long as both of these display the same endianess.
>
> If target that is in big endian, the hex renderer is perfectly fine.
> So, I am wondering if this is a general case for everyone, or it is
> just a specific case for me.
>
> Thanks you,
>
> Patrick
>
>-----------------------------------------------------------------------
-
>
>_______________________________________________
>cdt-debug-dev mailing list
>cdt-debug-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
>
>
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
