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

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

At Ericsson, we work with an architecture which uses 16-bits bytes
instead of the common 8-bits bytes. There are a few examples in the DSP
world of processors that work with 16, 24 or 32-bits bytes. 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 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 did a quick research of publicly available chips which use non-8-bits
bytes.

 - 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 uses 16-bits words
   http://www.atmel.com/products/microcontrollers/avr/megaavr.aspx

 - Some DSPs targetting audio have 16-bits or 24-bits memory words.
   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:

 - `octet` when referring to a chunk of 8 bits
 - `byte`, `target byte` or `target memory byte`, to be even more
   explicit, 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 octets or target bytes. 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).

For MI, the parameters representing numbers of bytes and offsets in 

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

should be in target memory bytes. This makes the API easier to use,
because it's impossible to request an invalid amount of bytes. 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 bytes.

  -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="Some error about non integral number of bytes."

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. Therefore,
it would be easier if those lengths were always in octets. 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 bytes
  gdbarch: add memory_byte_size method
  target: consider byte size when reading/writing memory
  remote: Consider byte size when reading/writing memory
  MI: Consider byte size when reading/writing memory

 gdb/arch-utils.c       |   9 +++
 gdb/arch-utils.h       |   1 +
 gdb/common/rsp-low.c   |  71 ++++++++++++++++-------
 gdb/common/rsp-low.h   |  16 +++---
 gdb/corefile.c         |   4 +-
 gdb/doc/gdb.texinfo    |  41 +++++++------
 gdb/doc/python.texi    |   5 +-
 gdb/gdbarch.c          |  23 ++++++++
 gdb/gdbarch.h          |   6 ++
 gdb/gdbarch.sh         |   4 ++
 gdb/gdbcore.h          |   6 +-
 gdb/gdbserver/server.c |   4 +-
 gdb/mi/mi-main.c       |  51 ++++++++++-------
 gdb/remote.c           | 153 +++++++++++++++++++++++++++----------------------
 gdb/target.c           | 121 +++++++++++++++++++++-----------------
 gdb/target.h           |  32 ++++++++---
 gdb/target/target.h    |  14 ++---
 17 files changed, 350 insertions(+), 211 deletions(-)

-- 
2.1.4