[RFC] TARGET_CHAR_BIT != HOST_CHAR_BIT

["Svein E. Seldal" <Svein.Seldal@solidas.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.

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.

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.

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.


Regards,
Svein