From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13504 invoked by alias); 29 Nov 2012 17:23:03 -0000 Received: (qmail 13463 invoked by uid 22791); 29 Nov 2012 17:22:59 -0000 X-SWARE-Spam-Status: No, hits=-5.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from ausc60pc101.us.dell.com (HELO ausc60pc101.us.dell.com) (143.166.85.206) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 29 Nov 2012 17:22:55 +0000 X-Loopcount0: from 10.175.216.250 From: To: CC: , Subject: Re: Memory-mapped peripheral registers, remote protocol and memory maps Date: Thu, 29 Nov 2012 17:23:00 -0000 Message-ID: References: <004701cdcd9d$e487ff90$ad97feb0$@beniston.com> <50B727B8.7040103@codesourcery.com> <009401cdce4f$03913a80$0ab3af80$@beniston.com> In-Reply-To: <009401cdce4f$03913a80$0ab3af80$@beniston.com> Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: 2012-11/txt/msg00097.txt.bz2 On Nov 29, 2012, at 11:31 AM, Jon Beniston wrote: >> The following command 'p' will only generate 'm' packet with the right s= ize. >>=20 >> (gdb) p *(unsigned int *) 0x8048608 >> Sending packet: $m8048608,4#3f...Packet received: 5589e583 >>=20 >>=20 >> (gdb) p *(char *) 0x8048608 >> Sending packet: $m8048608,1#3c...Packet received: 55 >>=20 >> I admit they are tricky. >=20 > Yes, this is fine from the command line, but ideally I would like somethi= ng that works when GDB is being driven by a GUI such as Eclipse, which may = not necessarily know the correct size to use. It does work in some cases, b= ut not all (i.e. when dumping memory). If so, that would be the GUI's issue. If GDB can be told what to do -- whi= ch appears to be the case -- then it's up to whoever does the telling to te= ll correctly. If GDB can do it but you ask it the wrong thing, it will obe= y and do the wrong thing. So don't do that. What's not clear to me is whether there is a *guarantee* that certain UI re= quests will produce certain "m" packets. Clearly there are a bunch of thin= gs that fall out of the current implementation, but if somehow the implemen= tation were to change and, say, that "p" command above is split into two m = packets, what then? By the current remote protocol specification, such a c= hange would be legal. Not terribly rational perhaps, but legal. For reliable access to memory mapped device registers, you'd need to have a= guarantee. For example: "A request for 1, 2, 4, or 8 bytes with a p or x = command, where the memory address is naturally aligned, will always become = a single remote protocol memory read of that same size. For other transfer= sizes and alignments, the request may or may not be split into pieces, and= the behavior for those is subject to change." Clearly you can propose any number of rules, but for starters you'd need a = documented rule so that users know what they can count on and implementers = know what they are required to preserve. paul