Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [dsdp-dd-dev] Memory service questions

There is an article about how the Memory View framework works.  You can find it here:

- 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

>> 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.


dsdp-dd-dev mailing list

Back to the top