Re: [RFC] TARGET_CHAR_BIT != HOST_CHAR_BIT

["Svein E. Seldal" <Svein.Seldal@solidas.com>]

Andrew Cagney wrote:
> So the problem is defining how many host|target bytes are transfered by 
> a specified length?  Or is the lenght in the host, or target space?
> 
> The d10v's data space is addressable down to an 8 bit boundary, but it's 
> code space is addressable down to only 32 bits.  Both code and data 
> pointers are mapped onto a single 8 bit addressable CORE_ADDR (see 
> d10v-tdep.c pointer to address and address to pointer).

When gdb is about to download large amounts of data over the a remote 
interface, it will break it up into smaller packets. These packets (the 
'M' packets) hold the destination address as its first argument. The 
download of the first 'M' packets goes well, but the successive M's 
within that segment fails. GDB assumes that when it has downloaded n 
bytes, it should increase the lma address by n for the next packet.

The problem is that the tic4x target doesnt work this way. It has the 
following proerty: sizeof(char)=sizeof(short)=sizeof(int)=sizeof(long)=1 
*and* is able to hold 32-bits of information. The tic4x target has 
absolutely no conception about bytes, only a databus of 32-bit width. 
One increase in a datapointer increases the physical address by one, but 
still one address spans 32-bit. Thus to store the information for a 
particular address, you need 32-bits of storeage. e.g.

	char foo[2] = { 1, 2 };

Is located in memory like this:

0x1000: 0x00000001
0x1001: 0x00000002

So you see, if a segment contains 256 bytes, GDB still needs to download 
256 bytes to the target (that's obvious), but the address-span of those 
256 bytes is only 64 (on target). So any lma address increases must be 
divided by 4 to be correct on this target.

As for the d10v solution, the tic4x is similar to the code-space of this 
  target. You could implement gdb this way, but I think you'll soon wind 
up in the same troubles: A char is still 32-bit, not the hardcoded 
8-bit. All accesses to non-32-bit boundary addresses will be invalid. 
Absolutely all addresses coming from binutils/BFD must be ajusted, 
because they are 32-bit oriented, not byte-oriented...

...but still, I'll keep an open mind to this turning out to be an 
implementable solution.

> I suspect that what's been proposed here would [further] overload the 
> already overloaded TARGET_CHAR_BIT.  Is something separate needed?

No and yes. Yes, because TARGET_CHAR_BIT doesn't affect the packet 
download lma incrementing. And no, because there already exists a 
set_gdbarch_char_bit() setting. But its commented out, so its not in 
use. This function/setting is probably what we would need for this port, 
if we could define it this way: TARGET_CHAR_BIT means "the number of 
bits required to represent the information stored in one unique address".

So my suggestion is that we reintroduce this setting, and use a macro 
like this to replace the code where needed.

#define TARGET_LENGTH(n) (n) * HOST_CHAR_BITS / TARGET_CHAR_BITS

(only gdbarchified, of course)

If the default value of the set_gdbarch_char_bit() setting is 8, well 
then it wont matter for most targets, as they dont need to the define 
nor change it's value. And it works transparently for everyone.

Why has the set_gdbarch_char_bit() setting been disabled?

> Keep in mind that this is so weird that the average programmer will 
> always forget to use this mechanism.  Unless, somehow, it's made very 
> natural.

Yeah, I know this may sound weird to some programmers. But it isnt 
unusual in DSP'world, as they are usually word-oriented to align better 
with the information they are processing. I will still try to press on 
for this feature, as I know that other Texas Instruments processors (of 
which have gcc support) have the same propery.


Regards,
Svein