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

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

On 15-04-10 01:42 PM, Eli Zaretskii wrote:
>> Date: Fri, 10 Apr 2015 12:01:00 -0400
>> From: Simon Marchi <simon.marchi@ericsson.com>
>> CC: <gdb-patches@sourceware.org>
>>
>>> I want GDB to be agnostic, as far as possible, to the size of 1 unit
>>> of memory.  Ideally, one unit will start as one unit in user-level
>>> commands, pass all the way down to the target level, which should know
>>> what one unit means.
>>
>> I totally agree with you, and I believe that's the idea you'll find implemented
>> in the patches.  The length is always passed in "units of memory" of whatever you
>> are trying to read or write.  The only thing is that I called a "unit of memory"
>> a "byte", which seems the friction point.  If it's just a wording issue, it can
>> be changed easily.  I just don't know what succinct term to use.
> 
> W could use the terminology that is already in use: "half-words" for
> 16 bits and "words" for 32 bits.  Would that be OK?

When you know what is the size of the data unit you are referring to that's fine.  But
we need another word or expression for when we don't know it.  For example, in the
-data-read-memory-bytes documentation, we would need to change:

  ‘count’
      The number of bytes to read. This should be an integer literal.

to something like

  ‘count’
      The number of addressable memory units to read. This should be an integer literal.

We can't use "byte", "half-words" or "words" here, since the doc should work for all the
platforms.  We could also use "addressable memory unit" or "unit of address resolution",
it just seems a bit verbose to me.

>> Ok, so if I understand correctly, you would be fine if the -data-read-memory-bytes
>> command accepted a length in number of memory units, as long as this unit is not
>> called a byte.
> 
> Yes.  Though it's unfortunate that the name of the command explicitly
> mentions "bytes".

There is also the parameter named byte-offset. Although I guess we could change it since
it's not really referred by name in the code, just the position.