This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [RFC] TARGET_CHAR_BIT != HOST_CHAR_BIT
- From: "Svein E. Seldal" <Svein dot Seldal at solidas dot com>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Mon, 02 Jun 2003 04:22:13 +0200
- Subject: Re: [RFC] TARGET_CHAR_BIT != HOST_CHAR_BIT
- References: <3ED6964E.2080509@solidas.com> <3EDA425B.6070209@redhat.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