From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10965 invoked by alias); 22 Aug 2008 08:36:01 -0000 Received: (qmail 10956 invoked by uid 22791); 22 Aug 2008 08:36:00 -0000 X-Spam-Check-By: sourceware.org Received: from ug-out-1314.google.com (HELO ug-out-1314.google.com) (66.249.92.175) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 22 Aug 2008 08:35:25 +0000 Received: by ug-out-1314.google.com with SMTP id o4so71961uge.39 for ; Fri, 22 Aug 2008 01:35:22 -0700 (PDT) Received: by 10.67.116.9 with SMTP id t9mr2287468ugm.65.1219394120641; Fri, 22 Aug 2008 01:35:20 -0700 (PDT) Received: by 10.67.117.5 with HTTP; Fri, 22 Aug 2008 01:35:20 -0700 (PDT) Message-ID: <1021db0c0808220135s7ff206fexbc0e410889414558@mail.gmail.com> Date: Fri, 22 Aug 2008 14:30:00 -0000 From: "Robin den Hertog" To: gdb@sourceware.org Subject: byte word and int(32) safe memory access? MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 20946f6c29858e66 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-08/txt/msg00249.txt.bz2 hey, I would like to be able to send bytes words and int's that are read/written as such to my embedded target. (some fpga's and other peripheral hardware need their registers to be read/written in one action). the protocol doesn't support this, what is more the way the `m' packet is defined it is unsure how it will handle the read at all. the gdb user manual says this about the m|M packet: The stub need not use any particular size or alignment when gathering data from memory for the response; even if addr is word-aligned and length is a multiple of the word size, the stub is free to use byte accesses, or not. For this reason, this packet may not be suitable for accessing memory-mapped I/O devices. I suggest a new u|U packet. (i suggest the packet uses binary data as some of the targets this could be used for don't have powerful processors and any(cpu) overhead we can spare is good in my book) i suggest using the first 3 bits of the first byte to describe the size of the data (000 for 8 bts 001 for 16 bits 010 for 64 bits, wich leaves plenty of room for the future) Then the last 5 bits to indicate the length. Then 2 bytes for the start address, and then the data (if any, none for read commands). i might be implementing something like this for my internship project (it would be nice if it was an accepted packet in the gdb protocol, instead of a add on that doesn't make it in). i say might because the decision to use gdb hasn't been made yet, but gdb is supported by more and more companies to talk to their chips so it would be nice to use gdb. the alternative is a simple custom application that allows remote read/write access, and possibly gdb server as well to allow for debugging. you could say i would be misusing gdb but the potential for faster development and testing (trough a scripting enviroment thath sends read/write commands to gdb) is there. what do you think? Robin -- Never fear, for I is here!