|Re: [dsdp-dd-dev] Memory service questions|
Pawel Piech wrote:
Jesper Eskilson wrote:As far as I know Wind River debugger doesn't deal with this use case. As far as DSF, since the MemoryByte is returned from the memory service, then the memory service implementation is responsible for setting the correct endiannss flag on each byte.Samantha Chan wrote:Re: Personalized endianess flags for each MemoryByteOn some systems, the endianess is not uniform for all memory on the system. Part of the memory could be in big endian while another part of it could be in little endian. The memory block and memory byte is modelled such that we can accommodate such system. We tag a endianess flag on each memory byte so that the UI can still render things correctly as the user crosses the boundary between big endian and little endian.I was actually looking for someone to ask about this.Our debugger backend uses the notion of a "location" to represent an addressable unit of memory. A location consists of a zone together with an address (int64_t). In order to read from memory, you need to define an address *and* a zone. Zones can be of different size, have different endianness, different alignment, they may be (partially) overlapping. This is used to implement things like different code and data memory, etc.In the 32/64-bit desktop world, this isn't much of an issue, but in the embedded world this kind of non-uniform memory stuff is pretty common. How should this be addressed (haha) in the DSF domain? How is WindRiver doing it?
I was not referring to the endianness, but rather about how to handle non-uniform memory.
Back to the top