From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55299 invoked by alias); 8 Apr 2015 19:56:30 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 55278 invoked by uid 89); 8 Apr 2015 19:56:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_40,SPF_PASS autolearn=ham version=3.3.2 X-HELO: usevmg20.ericsson.net Received: from usevmg20.ericsson.net (HELO usevmg20.ericsson.net) (198.24.6.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 08 Apr 2015 19:56:27 +0000 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 62.C8.12456.56135255; Wed, 8 Apr 2015 15:47:17 +0200 (CEST) Received: from elxcz23q12-y4.mo.ca.am.ericsson.se (147.117.188.8) by smtps-am.internal.ericsson.com (147.117.188.96) with Microsoft SMTP Server (TLS) id 14.3.210.2; Wed, 8 Apr 2015 15:56:22 -0400 From: Simon Marchi To: CC: Simon Marchi Subject: [PATCH 0/7] Support reading/writing memory on architectures with non 8-bits bytes Date: Wed, 08 Apr 2015 19:56:00 -0000 Message-ID: <1428522979-28709-1-git-send-email-simon.marchi@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00297.txt.bz2 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