| 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.1We 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.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?
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.
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).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?
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).
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.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?
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