Samantha,
To answer precisely your question, I'm talking about the size of the
addressable unit. After having checked how the Eclipse interacts with
the debugger, displaying 3 bytes per column is not the solution.
I'm going a little bit more in detail:
We are addressing DSPs that do not have very regular Architecture
comparing to the processor commonly supported.
First they have multiple data memory bank, second they can have specific
characteristics in term of memory access.
Here I'm focusing only on the second problem, I'll submit the other one
later ...
I take for example a DSP that has a Minumum Addressable Unit of 24 bits,
short integer are on 24 bits and long on 48 bits.
When Eclipse ask the debugger for a memory block, he's returning 24 bits
per memory address.
Example of the MI output:
-data-read-memory 0x8ca x 1 1 6
^done,addr="0x8ca",nr-bytes="6",total-bytes="6",next-row="0x8d0",prev-ro
w="0x8c4",next-page="0x8d0",prev-page="0x8c4",memory=[{addr="0x8ca",data
=["0x000000","0xffffff","0xfffffe","0xfffffd","0xfffffc","0xfffffb"]}]
But Eclipse memory view truncates the first 16bits and take only the 8
least significant bits to display memory area.
I think MAU could be calculated by Eclipse the first time he gets a
memory block by checking the output of data memory returns by the
debugger, counting its number of characters. "0x000000" would mean 24
bits, "0x0000" 16 bits and "0x00" 8 bits MAU. The MI standard fits this
requirement.
Taking that into account, may be you'll tell me "we won't be able to
display 24bits integers or 48 bits long datas".
An other point we notice is that today, the memory view emits MI command
-data-read-memory with word-format parameter always set to hexadecimal,
that means Eclipse computes these values before displaying them.
We think it's the job of the debugger to know how to display the data he
is accessing, not to the interface. We think the best solution to avoid
wrong display is to use ouputs formats as defined in chap. 8.4 of GdB
6.3 documentation (integer, signed or unsigned, octal ...), then
debugger will return correctly formatted datas, with sign bits correctly
set according to the processor Architecture and so on.
We 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.
Please don't hesitate to ask me for details or explanation
Best regards
Denis (STMicroelectronics/ France)
Samantha Chan wrote:
Hi Dennis -
I am working on the new Memory View in Eclipse 3.1.
I saw your requirement on displaying 3 bytes MAU. I'd like to make
sure
that the new Memory View satisfies your requirement.
Could you please explain to me what a MAU is? By 3-bytes MAU, did you
mean
displaying 3 bytes per column? Or are you talking about the size of
your
addressable unit in your memory block?
Thanks...
Samantha
Denis PILAT
<denis.pilat@st.c
om>
To
Sent by: cdt-debug-dev@xxxxxxxxxxx
cdt-debug-dev-adm
cc
in@xxxxxxxxxxx
Subject
[cdt-debug-dev] Memory view
03/07/2005 09:45
AM
Please respond to
cdt-debug-dev
Hi all,
I'm using CDT 2.1 into Eclipse 3.0.1,
In the memory view (debug perspective) we can see "standard processors"
that have MAU on 1, 2, 4 or 8 bytes, but I need to display 3 bytes MAU.
(bad luck you might say :-)
Has anybody already faced this problem or heard about an enhancement of
this view to allow the display of such data ?
Thanks in advance for your answer.
Denis PILAT
STMicroelectronics / France
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
