Skip to main content

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

Jesper Eskilson wrote:
Pawel Piech wrote:
Jesper Eskilson wrote:
Samantha Chan wrote:

Re:  Personalized endianess flags for each MemoryByte

On 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?

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.

I was not referring to the endianness, but rather about how to handle non-uniform memory.

Our memory service retrieves (and re-retrieves as necessary) the memory map from the debugger engine and calls the engine to retrieve memory only for the active regions. But here as well, AFAIK, the regions are assumed to have the same alignment, addressable size, etc. I think for your use case, where you have these different zones which are potentially overlapping, you may want to enhance (or replace) the existing DsfMemoryBlock implementation (and DsfMemoryBlockRetrieval) to take additional parameters. Samantha's pointer to the memory view framework may help you figure out how to accomplish this.

I'm also CC'ing cdt-dev, because other folks using CDT have already dealt with this issue.

Cheers,
Pawel


Back to the top