This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[PATCH 0/7] Support reading/writing memory on architectures with non 8-bits bytes
- From: Simon Marchi <simon dot marchi at ericsson dot com>
- To: <gdb-patches at sourceware dot org>
- Cc: Simon Marchi <simon dot marchi at ericsson dot com>
- Date: Wed, 8 Apr 2015 15:56:12 -0400
- Subject: [PATCH 0/7] Support reading/writing memory on architectures with non 8-bits bytes
- Authentication-results: sourceware.org; auth=none
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