From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 52827 invoked by alias); 15 Apr 2015 19:47:52 -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 52804 invoked by uid 89); 15 Apr 2015 19:47:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: usevmg21.ericsson.net Received: from usevmg21.ericsson.net (HELO usevmg21.ericsson.net) (198.24.6.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 15 Apr 2015 19:47:48 +0000 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 35.E5.17241.A5D5E255; Wed, 15 Apr 2015 14:45:14 +0200 (CEST) Received: from elxcz23q12-y4.mo.ca.am.ericsson.se (147.117.188.8) by smtps-am.internal.ericsson.com (147.117.188.75) with Microsoft SMTP Server (TLS) id 14.3.210.2; Wed, 15 Apr 2015 15:47:45 -0400 From: Simon Marchi To: CC: Simon Marchi Subject: [PATCH v2 0/7] Support reading/writing memory on architectures with non 8-bits addressable memory Date: Wed, 15 Apr 2015 19:47:00 -0000 Message-ID: <1429127258-1033-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/msg00588.txt.bz2 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