From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20042 invoked by alias); 29 Nov 2012 17:57:33 -0000 Received: (qmail 20027 invoked by uid 22791); 29 Nov 2012 17:57:31 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,SARE_RECV_UK2NET2 X-Spam-Check-By: sourceware.org Received: from smtprelay0090.hostedemail.com (HELO smtprelay.hostedemail.com) (216.40.44.90) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 29 Nov 2012 17:57:26 +0000 Received: from filter.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay01.hostedemail.com (Postfix) with SMTP id EFEA5CA66E; Thu, 29 Nov 2012 17:57:24 +0000 (UTC) X-Panda: scanned! X-Spam-Summary: 2,0,0,,d41d8cd98f00b204,jon@beniston.com,:::::,RULES_HIT:10:355:379:541:542:599:601:945:973:982:988:989:1155:1260:1277:1311:1313:1314:1345:1359:1437:1515:1516:1518:1534:1541:1587:1593:1594:1711:1730:1747:1777:1792:2110:2194:2199:2393:2553:2559:2562:2689:2693:2736:2892:3027:3138:3139:3140:3141:3142:3354:3622:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:4250:5007:6119:7875:7903:7904:8603:9108:10004:10400:10848:11658:11914:12517:12519,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fn,MSBL:0,DNSBL:none,Custom_rules:0:0:0 X-Session-Marker: 6A62656E6973746F6E40756B322E6E6574 X-Filterd-Recvd-Size: 2817 Received: from JonPC (cpc21-croy19-2-0-cust368.croy.cable.virginmedia.com [94.174.157.113]) (Authenticated sender: jbeniston@uk2.net) by omf12.hostedemail.com (Postfix) with ESMTPA; Thu, 29 Nov 2012 17:57:24 +0000 (UTC) From: "Jon Beniston" To: Cc: , References: <004701cdcd9d$e487ff90$ad97feb0$@beniston.com> <50B727B8.7040103@codesourcery.com> <009401cdce4f$03913a80$0ab3af80$@beniston.com> In-Reply-To: Subject: RE: Memory-mapped peripheral registers, remote protocol and memory maps Date: Thu, 29 Nov 2012 17:57:00 -0000 Message-ID: <009601cdce5a$e6659d50$b330d7f0$@beniston.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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/msg00098.txt.bz2 Hi Paul, > > Yes, this is fine from the command line, but ideally I would like something > 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, but not > all (i.e. when dumping memory). > > If so, that would be the GUI's issue. If GDB can be told what to do -- which > appears to be the case -- then it's up to whoever does the telling to tell > correctly. If GDB can do it but you ask it the wrong thing, it will obey and do > the wrong thing. So don't do that. It doesn't seem like the right approach to me to require each GDB GUI (or user) to have detailed knowledge of the target h/w. Wouldn't it be better if this info came from the target, in the same way the memory map or target description does? GDB already has the hooks to deal with this (via the mem command), it's just a case of how to best get that info and then actually make use of it. I don't think it would make sense to propagate this target information to the GUI to require it to only generate correct commands, otherwise you are requiring the problem to be solved in each GUI, rather than just in one place in GDB. > What's not clear to me is whether there is a *guarantee* that > certain UI requests will produce certain "m" packets. Clearly > there are a bunch of things that fall out of the current implementation, > but if somehow the implementation were to change and, > say, that "p" command above is split into two m packets, what then? Well, I would expect that any command should respect the attributes set via the 'mem' command, if it doesn't, it's a bug, if it can't, it should generate an error message? Cheers, Jon