Re: [dsdp-dd-dev] Memory service questions

[Samantha Chan <chanskw@xxxxxxxxxx>]

There is an article about how the Memory
View framework works.  You can find it here:
http://www.eclipse.org/articles/article.php?file=Article-MemoryView/index.html

- Samantha

From:	Jesper Eskilson <jesper.eskilson@xxxxxx>
To:	Device Debugging developer discussions <dsdp-dd-dev@xxxxxxxxxxx>
Date:	17/10/2008 05:17 AM
Subject:	Re: [dsdp-dd-dev] Memory service questions

---

Pawel Piech wrote:
> Hi Jasper,
> The memory service and its integration with the memory view has been
> written by Francois, who has been on a leave last couple of months.
 I 
> believe he is returning from his leave shortly so he can give much
> better answers, but I will try to give you as much information as
I 
> remember:

Ok. I'll put this on hold then until he's back. (Should I send him a 
personal note to take a look at this, or should I just wait for him to
catch up on his mail?)

> Jesper Eskilson wrote:
>>
>> I'm implementing the memory service for our DSDP/DD debugger 
>> integration, and I got some questions/problems about how DSF expects
>> the memory service to behave.
>>
>> (We're working against 1.0.0-RC4.)
> Memory service has not changed much in 1.1
>>
>> I noticed is that getMemory() is called several times for each
update 
>> (5 times and upwards), and when you attempt to scroll it is flooded
>> with getMemory() calls. The MemoryByte array returned has the
readable 
>> flag set, and all other cleared. Should I be setting other flags
as 
>> well, or is the flooding caused by something else?
> We assume that the memory service will implement caching and potentially
> coalescing of requests for memory to target.  So all requests
from the 
> memory rendering are channeled directly to the service.

The issue here is that I get alot of *identical* getMemory() requests 
(same address, same range, same wordsize, etc.). If I start scrolling,
the service is sometimes flooded with calls until I get a OutOfMemory 
error.


>>
>> In general, it is not very clearly documented exactly how DSF
expects 
>> the flags field to be set by the implementing service. What is
the 
>> exact semantics of the HISTORY_KNOWN field?
> MemoryByte (and its flags) come from the IMemoryBlock and 
> IMemoryBlockExtension interfaces.  We decided to use these at
the 
> service level as well for simplicity, but some of the flags, especially
> history and changed are managed by the memory block implementation
> (DsfMemoryBlock).

Does that mean that the memory service should just leave these? I noted
that the GDB MIMemory service does not set any flags at all; at least at
the sites I could find where it manipulated the MemoryByte objects. (I
may have missed some places, though).

>>
>> Regarding endianness: why does each memory byte carry a flag about
>> endianness? Seems a rather odd way to implement endianness, and
it 
>> makes a little backwards to communicate with out debugger backend
>> which handles all byte-swapping itself. When reading from the
target, 
>> I have four (overloaded) functions, which basically look like
this:
>>
>>     Read(uint32_t count, uint8_t *buf, ...);
>>     Read(uint32_t count, uint16_t *buf, ...);
>>     Read(uint32_t count, uint32_t *buf, ...);
>>     Read(uint32_t count, uint64_t *buf, ...);
>>
>> Which means that if you, for example, want to read 32-bit units
from 
>> the target, you use a uint32_t buffer, and you automatically get
the 
>> correct endianness.
>>
>> I'm not sure how to present this in a way suitable to DSF. The
>> getMemory() documentation say that the returned bytes should 
>> "represent the target endianness", but I'm not exactly
sure what that 
>> means.
>>
>> Regarding word sizes: the GDB MIMemory service only supports a
1 byte 
>> word size. I could not find an active bugreport on that. Should
I add 
>> one?
>>
> This is where my knowledge of the memory service fades :-(  But
I do 
> know that the memory service implementation is basically a first-cut
> implementation, and really only the basic use cases were considered.
 So 
> endianness and word size issues have not been worked out.  But
some of 
> the CDI framework users, e.g. Freescale have dealt with these issues
and 
> it would be useful to look at their implementation and see where the
DSF 
> interface is lacking.

Is there any documentation available on how the (new) memory rendering
system works? I found the docs for the 
org.eclipse.debug.ui.memoryRenderings extension point, but it does 
really help in understanding how the memory rendering architecture works.

-- 
/Jesper

_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev