Re: [cdt-debug-dev] address spaces

["Alain Magloire" <alain@xxxxxxx>]

> 
> Hello All,
> 
> My name is Aaron Spear, I am the debugger architect for Accelerated
> Technology.  I have been lurking on this list, but thought I would throw
> a few thoughts in on this thread as this is something that we spent
> quite a bit of time thinking about.  My intention is that this is just
> food for thought while others are out, I certainly don't want to exclude
> anyone from the conversation in their absence...
> 
> We have a "from scratch" implementation of the Eclipse debug model in
> our Nucleus EDGE product.  (currently no use of the CDT).  We support a
> number of different architectures including RISC's, CISC's and DSP's.
> Especially for DSP support the notion of different address spaces was
> very important.  We did something very similar to what John described:
> 
> Addresses as strings are formatted=20
> 
> <space name>:<offset>
> 
> "Space name" is something that is data driven and comes from the
> architecture/core specific implementation.  If a DSP has "X" and "Y"
> address spaces it uses those names, e.g."X:0x1000".  There are no
> restrictions on the space name other than it be one or more alphanumeric
> characters with no white space.  One extension that we allowed, because
> it makes life with simple single address space processors nice, is that
> if the address space is NOT specified (e.g. "0x10000000"), then the
> default address space for that core is used (often the only address
> space).  So for cores that don't have RISC's that don't have multiple
> address spaces (i.e. no hardware address spaces introduced by the MMU
> configuration) the user isn't burdened with typing extra information.
> 
> Note that "offset" is defined as the number of "addressable units" from
> the base of the address space. This is simply bytes for the vast
> majority of architectures, but for some that can only address things on
> 16 bit boundaries for example, the offset is actually in terms of 16 bit
> quantities.
> 
> As far as the implementation of an address itself, the core specific
> module in our implementation is the only component that knows anything
> about how an address actually works.  It creates addresses and provides
> all ability to do math with addresses, convert to and from strings, etc.
> As such it can provide whatever implementation it wants for the address
> itself.  There are of course some other components that know details
> about addresses as well due to the nature of what they do (elf/dwarf for
> example uses integer addresses)=20
> 

Interesting, thanks !!
Do you have an interface/class/object that defines what is an "address" ?