[PATCH v2 0/7] Support reading/writing memory on architectures with non 8-bits addressable memory

[Simon Marchi <simon dot marchi at ericsson dot com>]

Here is the second version of this patch. The biggest change is to use
"addressable memory unit" for the amount of data associated to an
address in memory, and "byte" for an 8-bits chunk.

I added a section in the manual to describe what an addressable memory
unit is, and the difference between that and a byte in the context of
gdb.

Below is the original message, with the vocabulary adjusted:

At Ericsson, we work with an architecture which uses memory with
addressable units of 16-bits instead of the common 8-bits. There are a
few examples in the DSP world of processors that work with 16, 24 or
32-bits addressable memory units. Over the past year or so, we have
adapted gdb to work with our architecture and we now feel it's the right
time to start contributing some of the changes back. On gdb's side, it
should be a step towards supporting a new range of chips. On our side,
it will help us stay closer to mainline.

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 addressable units, 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 addressable
unit 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 did a quick research of publicly available chips which use non-8-bits
addressable memory units.

 - TI C54x family (16-bits memory)
   http://www.ti.com/lsds/ti/dsp/c5000_dsp/c54x/products.page

   It seems like work had been done to port an ancient GDB for the
   earlier C4x family a long time ago, but I can't find the source
   anywhere. They must have done changes similar to ours in order to
   support the 16-bits memory. If you know where to find that source,
   I'd be really interested to see it!
   http://www.elec.canterbury.ac.nz/c4x/

 - Atmel ATMega family, the flash program space has 16-bits units
   http://www.atmel.com/products/microcontrollers/avr/megaavr.aspx

 - Some DSPs targetting audio have 16-bits or 24-bits memory units.
   http://www.analog.com/media/en/technical-documentation/data-sheets/ADSP-21990.pdf

 - Another one by Freescale
   http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=DSP56321


Terminology
-----------

Talking about this stuff becomes quickly confusing without a consistent
terminology. Here is what I try to stick to in my messages,
documentation and code:

 - `byte` when referring to a chunk of 8 bits
 - `addressable memory unit` when referring to one chunk of the
   addressable size of the memory


API proposition
---------------

The current APIs (MI and RSP) need to be clarified in order to be usable
with 16-bits (and other) systems. In the current state, it is not clear
if a length should be expressed in bytes or addressable memory units.
Here are the changes we suggest. They are based on what we have been
using for some time, so we are confident it works quite well. This should
not affect any existing system using 8-bits memory (IOW, everything
supported right now), since an addressable memory unit and a byte are the
same thing for them.

For MI, the parameters representing lengths and offsets in memory in 

  -data-read-memory-bytes
  -data-write-memory-bytes

should be in addressable memory units. This makes the API easier to use,
because it's impossible to request an invalid amount of units (e.g.
trying to read 3 bytes on a 16-bits addressable system). Also, it feels
more natural this way, because the client expresses the length as the
number of memory addresses it wants to read. Here is an example MI
session with an hypothetic system that uses 16-bits addressable memory.

  -data-read-memory-bytes -o 4096 0 4
  ^done,memory=[{begin="0x1000",offset="0x0000",end="0x1004",contents="aaaabbbbccccdddd"}]

  -data-write-memory-bytes 4096 eeeeffff 3
  ^done

  -data-read-memory-bytes -o 4096 0 4
  ^done,memory=[{begin="0x1000",offset="0x0000",end="0x1004",contents="eeeeffffeeeedddd"}]

  -data-write-memory-bytes 4096 ee
  ^error,msg="Hex-encoded 'ee' must represent an integral number of addressable memory units."

The error case in the last command is similar to the error thrown when
trying to write an odd number of hex digits. The number of given hex
digits must represent an integral number of bytes of the memory you are
writing to.

For RSP's m, M and X packets, the "length" parameters are used to
correctly encode or decode the packet at a low level, where we don't
want to have to deal with different target byte sizes. Also, for a
network protocol, it would make sense to use a fixed-sized unit.
Therefore, it would be easier if those lengths were always in bytes.
Here is an example that corresponds to the previous MI example.

   -> $m1000,8#??
   <- aaaabbbbccccdddd

   -> $M1000,6:eeeeffffeeee#??
   <- OK

   -> $m1000,8#??
   <- eeeeffffeeeedddd

If there are any other RSP packets or MI commands that need such
clarification, it will be on a case-by-case basis, whatever makes more
sense for each particular one.


Simon Marchi (7):
  Various cleanups in target read/write code
  Cleanup some docs about memory write
  Clarify doc about memory read/write and non-8-bits addressable memory
    unit sizes
  gdbarch: add addressable_memory_unit_size method
  target: consider addressable unit size when reading/writing memory
  remote: consider addressable unit size when reading/writing memory
  MI: consider addressable unit size when reading/writing memory

 gdb/arch-utils.c       |   9 +++
 gdb/arch-utils.h       |   1 +
 gdb/common/rsp-low.c   |  68 +++++++++++++------
 gdb/common/rsp-low.h   |  18 ++---
 gdb/corefile.c         |   4 +-
 gdb/doc/gdb.texinfo    |  56 ++++++++++------
 gdb/doc/python.texi    |   5 +-
 gdb/gdbarch.c          |  23 +++++++
 gdb/gdbarch.h          |   7 ++
 gdb/gdbarch.sh         |   5 ++
 gdb/gdbcore.h          |   6 +-
 gdb/gdbserver/server.c |   4 +-
 gdb/mi/mi-main.c       |  56 +++++++++-------
 gdb/remote.c           | 174 +++++++++++++++++++++++++++----------------------
 gdb/target.c           | 121 +++++++++++++++++++---------------
 gdb/target.h           |  39 ++++++++---
 gdb/target/target.h    |  10 +--
 17 files changed, 381 insertions(+), 225 deletions(-)

-- 
2.1.4