Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [dsdp-dd-dev] Re: Some thoughts on DSF

Pawel Piech wrote:

7) Memory addressing: are there any plans for DSF to incorporate an extension to the IAddress interface, in order to be able to see different memory zones with different characteristics?
I don't really understand the problems of the memory service and we definitely use some outside expertise on it. In fact I was wondering recently whether we really need to use the IAddress interface to represent addresses. From your comment it seems that using IAddress is important, so I would like to know more about how you would like to see
the related APIs evolve.

In order to handle various weird architectures (we have alot of those...), our debugger API allows memory to be divided into zones, and uses a pair {uint32_t zone, int64_t address} to represent a location in memory or registers. You can think of them as multiple address-spaces with different attributes (such as endianness). Zones may overlap, meaning that one memory location can exist in several different zones. The debugger API can in that case map an address in one zone to a different zone (possibly yielding a new address).

We are currently ducking this issue by treating the default zone as the only available zone. This works reasonably well at the moment, but we'll need a better solution further down the road.

A possible solution would be to "serialize" all zones, putting them all in the same 64-bit address space, but I'm not sure if that is feasible for all our targets.

We'll have to have some more internal discussions here before we can say anything about (preferred) API extensions.



Back to the top