[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-debug-dev] Memory view
|
Hi all -
In Eclipse 3.1, there is an extension to IMemoryBlock interface,
IMemoryBlockExtension. IMemoryBlockExtension has a method,
#getAddressbileSize(), for getting the addressable size of the memory
block. (I notice the typo in this API, I will submit a patch to fix this
shortly.) When called, the memory block is supposed to return the size of
the smallest addressable unit of the memory block in number of bytes. The
default renderings provided by the debug framework supports any addressable
unit size returned by the memory block.
If you are interested in learning more about this feature, look at this bug
report:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=78335
So, when CDT moves to the new Memory View, CDT needs to return the correct
addressable size for its target and return the bytes as reported by GDB.
The rest should be handled by the default renderings provided by the debug
framework.
Let me know if you have more question.
Thanks...
Samantha
"Mikhail
Khodjaiants"
<mikhailk@xxxxxxx To
> <cdt-debug-dev@xxxxxxxxxxx>
Sent by: cc
cdt-debug-dev-adm
in@xxxxxxxxxxx Subject
Re: [cdt-debug-dev] Memory view
03/08/2005 12:38
PM
Please respond to
cdt-debug-dev
Denis,
The Eclipse platform provides the generic debug framework. The Memory view
is a part of this framework.
The CDT is using the Memory view and it's standard renderings. The problem
you are describing is CDT-related, or, to be more accurate, it's gdb/mi
implementation.
Using formatting features provided by gdb was considered as an option and
maybe we should revisit it. Please, submit an enhancement request in
Bugzilla to CDT/Debug.
Thanks,
Mikhail Khodjaiants
----- Original Message -----
From: "Denis PILAT" <denis.pilat@xxxxxx>
To: <cdt-debug-dev@xxxxxxxxxxx>
Sent: Tuesday, March 08, 2005 12:09 PM
Subject: Re: [cdt-debug-dev] Memory view
> 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
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
