Re: [PATCH 0/7] Support reading/writing memory on architectures with non 8-bits bytes

[Simon Marchi <simon.marchi@ericsson.com>]

On 15-04-09 04:20 AM, Eli Zaretskii wrote:
>> From: Simon Marchi <simon.marchi@ericsson.com>
>> CC: Simon Marchi <simon.marchi@ericsson.com>
>> Date: Wed, 8 Apr 2015 15:56:12 -0400
>>
>> On such a system, memory is addressable in atomic chunks of 16-bits. On
>> a "normal" system, you have 8 bits of data associated with each memory
>> address:
>>
>>   Address    Data
>>   ---------------
>>   0x1000     0xaa
>>   0x1001     0xbb
>>   0x1002     0xcc
>>   0x1003     0xdd
>>
>> whereas on a system with 16-bits bytes, you have 16-bits of data per
>> address:
>>
>>   Address    Data
>>   ---------------
>>   0x1000   0xaaaa
>>   0x1001   0xbbbb
>>   0x1002   0xcccc
>>   0x1003   0xdddd
>>
>> To support these systems, GDB must be modified to consider the byte size
>> when reading/writing memory. This is what this first patch series is
>> about.
>>
>> Also, on these systems, sizeof(char) == 1 == 16 bits. There is therefore
>> many places related to types and values handling that need to be
>> modified. This will be the subject of subsequent patch series.
> 
> I wonder: wouldn't it be possible to keep the current "byte == 8 bits"
> notion, and instead to change the way addresses are interpreted by the
> target back-end?
> 
> IOW, do we really need to expose this issue all the way to the higher
> levels of GDB application code?

Hi Eli,

I don't think there is an elegant way of making this work without gdb
knowing at least a bit about it. If you don't make some changes at one
level, you'll end up needing to make the equivalent changes at some other
level (still in gdb core). We tried a few different combinations, and
I don't know of any where we don't need to touch the core of gdb at some
point. I'd be happy to be proven wrong though!

From what I understand, your suggestion would be to treat addresses as
indexes of octets in memory. So, to read target bytes at addresses 3
and 4, I would have to ask gdb for 4 "gdb" bytes starting at address 6.

                                              size == 2
                                        v-------------------v
          +---------+---------+---------+---------+---------+---------+
real idx  |    0    |    1    |    2    |    3    |    4    |    5    |
          +----+----+----+----+----+----+----+----+----+----+----+----+
octet idx |  0 |  1 |  2 |  3 |  4 |  5 |  6 |  7 |  8 |  9 | 10 | 11 |
          +----+----+----+----+----+----+----+----+----+----+----+----+
                                        ^-------------------^
                                              size == 4

The backend would then divide everything by two and read 2 target bytes
starting at address 3.

If we require the user or the front-end to do that conversion, we just push
the responsibility over the fence to them. The interface will be quite poor
and unintuitive. For the developer working with that system 8 hours per day,
a size of 1 is one 16-bits byte. His debugger should understand that
language.

If I have a pointer p (char *p) and I want to examine memory starting at p,
I would do "x/10h p". That wouldn't give me what I want, as it would give me
memory at p/2.

Also, the gdb code in the context of these platforms becomes instantly more
hackish if you say that the address variable is not really the address we want
to read, but the double. There are enough things in as it is to scare new gdb
developers, we do not need any more :).

Another problem: the DWARF information describes the types using sizes in
target bytes (at least in our case, other implementations could do it
differently I suppose). The "char" type has a size of 1 (1 x 16-bits).
So, when you "print myvar", gdb would have to know that it needs to convert
the size to octets to request the right amount of memory.

I think the solution we propose is the one that models the best the debugged
system and therefore is the least hacky. From a gdb development point of view,
it makes things clear and explicit.

Does this answer you concerns?

Simon