Address generation question

Address generation question

[Timothy Wall]

I'm working on support for a DSP that has a dual addressing architecture (actually quite common in DSPs).  That in itself is not too big a problem, since GDB's CORE_ADDR can be made sufficiently large to include flags to indicate a particulare address bus.  The issue I'm working on is that one bus addresses by octet, while another addresses by 16-bit word.  When generating a new address from a base and an octet count, 0x1000 + 2 octets in the first case results in 0x1002, while in the second it results in 0x1001.   (At one time it was suggested to represent the second address as 0x2002, effectively directly mapping all octets, but while this makes easy integration into GDB, it's really ugly to use in practice, requiring the programmer to translate the addresses back to what they "really" are).

I'd like to know if anyone knows of any structures already built into GDB that might be suited to handling this arrangement.  I haven't found any, so I figured I'd simply build on some previous DSP work I've done which allows GDB to handle architectures with non-octet bytes (i.e., the least addressible unit on the target system is something other than 8 bits).

My proposed solution is to encapsulate the address generation bits into a macro, ADDR_OFFSET(a,b), where 'a' is the starting CORE_ADDR and 'b' is the octet offset count.  The result of this macro is assigned to the new address.  This makes it relatively easy to generate an offset appropriate to the addressing bus represenged in 'a'.  I'm not sure yet if there are places where intermediate values need to be saved which might lose the initial address context, though.

Thanks for any input

T.

Re: Address generation question

[Andrew Cagney]

Have a look at the d10v.  It has a 16 bit instruction word and an 8 bit 
data word.

There are syntatic constructs available for specifying that an address 
should be in the instruction or data space vis:

	print *(@data int *)0x1234

this is handed by the address to pointer and pointer to address code.

Andrew

Re: Address generation question

[Michael Snyder]

Timothy Wall wrote:
> 
> I'm working on support for a DSP that has a dual addressing architecture (actually quite common in DSPs).  That in itself is not too big a problem, since GDB's CORE_ADDR can be made sufficiently large to include flags to indicate a particulare address bus.  The issue I'm working on is that one bus addresses by octet, while another addresses by 16-bit word.  When generating a new address from a base and an octet count, 0x1000 + 2 octets in the first case results in 0x1002, while in the second it results in 0x1001.   (At one time it was suggested to represent the second address as 0x2002, effectively directly mapping all octets, but while this makes easy integration into GDB, it's really ugly to use in practice, requiring the programmer to translate the addresses back to what they "really" are).
> 
> I'd like to know if anyone knows of any structures already built into GDB that might be suited to handling this arrangement.  I haven't found any, so I figured I'd simply build on some previous DSP work I've done which allows GDB to handle architectures with non-octet bytes (i.e., the least addressible unit on the target system is something other than 8 bits).
> 
> My proposed solution is to encapsulate the address generation bits into a macro, ADDR_OFFSET(a,b), where 'a' is the starting CORE_ADDR and 'b' is the octet offset count.  The result of this macro is assigned to the new address.  This makes it relatively easy to generate an offset appropriate to the addressing bus represenged in 'a'.  I'm not sure yet if there are places where intermediate values need to be saved which might lose the initial address context, though.

Use gdbarch_pointer_to_address and gdbarch_address_to_pointer.
Internally GDB can be made to store addresses as normal byte pointers, 
while externally they will be in the target format.  This is normal for
debugging harvard architectures.