From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28484 invoked by alias); 29 Nov 2012 11:23:41 -0000 Received: (qmail 28472 invoked by uid 22791); 29 Nov 2012 11:23:40 -0000 X-SWARE-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,BAYES_20,KHOP_THREADED,RCVD_IN_DNSWL_NONE,SARE_RECV_UK2NET2 X-Spam-Check-By: sourceware.org Received: from smtprelay0041.hostedemail.com (HELO smtprelay.hostedemail.com) (216.40.44.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 29 Nov 2012 11:23:36 +0000 Received: from filter.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay08.hostedemail.com (Postfix) with SMTP id 9A13C234286; Thu, 29 Nov 2012 11:23:34 +0000 (UTC) X-Panda: scanned! X-Session-Marker: 6A62656E6973746F6E40756B322E6E6574 X-Filterd-Recvd-Size: 2093 Received: from JonPC (cpc21-croy19-2-0-cust368.croy.cable.virginmedia.com [94.174.157.113]) (Authenticated sender: jbeniston@uk2.net) by omf09.hostedemail.com (Postfix) with ESMTPA; Thu, 29 Nov 2012 11:23:33 +0000 (UTC) From: "Jon Beniston" To: "'Yao Qi'" Cc: References: <004701cdcd9d$e487ff90$ad97feb0$@beniston.com> <50B727B8.7040103@codesourcery.com> In-Reply-To: <50B727B8.7040103@codesourcery.com> Subject: RE: Memory-mapped peripheral registers, remote protocol and memory maps Date: Thu, 29 Nov 2012 11:23:00 -0000 Message-ID: <005301cdce23$e1b0f3e0$a512dba0$@beniston.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: 2012-11/txt/msg00090.txt.bz2 Hi Yao, > I don't understand your problem. Anything wrong when you use 'm' packet > to read the content of memory-mapped register? Supposing a 32-bit regist= er > is mapped at address 0x00d000, packet 'm 0x0x00d000 4' should be able read > the contents of this register. Your stub should know where each register= is > mapped, and when gets a 'm' packet, get the content of register by some > way, and reply it to GDB. In this way, the memory-mapped registers are > transparent to GDB, and user has to access them via address. In some cases, there might be a large variety of inter-mixed 8/16/32-bit re= gisters, which you might not have the space to cater for in a small stub. C= an we be sure that GDB will only generate a 'm 0x0x00d000 4' packet? It wou= ld be tricky for a stub to deal with a packet of a larger size (say if the = register area is opened in a memory viewer). Also, it would be nice to prev= ent reads from certain addresses, in case they have side effects (i.e FIFOs= , etc). I would have thought it would be better to have this logic in GDB, rather t= han each stub, given that it already has the relevant commands. Cheers, Jon