Re: [RFC] TARGET_CHAR_BIT != HOST_CHAR_BIT

[Andrew Cagney <ac131313 at redhat dot com>]

> Hi,
>
> To be able to port the tic4x target, I am forced to take action towards supporting TARGET_CHAR_BIT != 8 and TARGET_CHAR_BIT != HOST_CHAR_BIT. (TARGET_CHAR_BIT is 32 on this specific target.)
>
> First up for me is the load_section_callback() function in symfile.c - it handles the "load" command when doing remote debugging. It downloads x bytes to the target, and then increases the lma by x. Since TARGET_CHAR_BIT != HOST_CHAR_BIT this isnt correct.

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?

When you say TARGET_CHAR_BIT is 32, what exactly do you mean?  Is 32 
bits a fundamental limitation of the hardware or a data type selected 
for efficiency reasons?  Does debug info indicate that ``char'' is 8 
bits or more in size?  GDB uses TARGET_CHAR_BIT, on stabs, do decide the 
size of 'char'.

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).

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

> The simplest way to fix this issue (more or less globally) would be to declare a macro or function, target_addr_increase_from_buffersize(), or something, that calculates the lma increase from x with the aid of TARGET_CHAR_BIT (and TARGET_HOST_BIT).

> We need to make a decision of how to approach this issue. I will still keep porting the tic4x port in my local sandbox, and make this work for me. But as it requires me to make global adaptations, I would surely like to do this with the blessing of the community.
>
> 1) IMHO can assume that TARGET_CHAR_BIT and HOST_CHAR_BIT are multiplum of 8. I havn't seen _any_ targets yet that break with this rule.

Hopefully any hardware not complying with this has been switched off :-)

> 2) How should we incorporate these macros/function in regards of the gdbarch model?  Maby we should make an own gdbarch "attribute" that the targets can define.

The mechanism should always be present and should always be used.

> 3) We need to hunt and track down any portions of the gdb code that has issues with this. I can think of several occations where this will be a problem: - All target pointer arithmetics on host, - buffers and structs, etc. Looking briefly at my old tic4x-gdb patch (pre 5.0), I'd estimate approx. 500 changes to global sources, in over 50 files.

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.

Andrew