From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 68381 invoked by alias); 11 Jun 2015 21:10:10 -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 68346 invoked by uid 89); 11 Jun 2015 21:10:09 -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; Thu, 11 Jun 2015 21:10:07 +0000 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id D4.60.06409.73399755; Thu, 11 Jun 2015 15:55:03 +0200 (CEST) Received: from [142.133.110.144] (147.117.188.8) by smtp-am.internal.ericsson.com (147.117.188.86) with Microsoft SMTP Server id 14.3.210.2; Thu, 11 Jun 2015 17:10:03 -0400 Message-ID: <5579F92B.5000006@ericsson.com> Date: Thu, 11 Jun 2015 21:10:00 -0000 From: Simon Marchi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Pedro Alves , Subject: Re: [PATCH v2 0/7] Support reading/writing memory on architectures with non 8-bits addressable memory References: <1429127258-1033-1-git-send-email-simon.marchi@ericsson.com> <555E1989.7010407@redhat.com> <5579F856.9030202@ericsson.com> In-Reply-To: <5579F856.9030202@ericsson.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00238.txt.bz2 On 15-06-11 05:06 PM, Simon Marchi wrote: > On 15-05-21 01:44 PM, Pedro Alves wrote: >> This confuses me and gives me lots of pause. My immediate reaction >> is, "well, that's odd. what's different compared to MI here?". I'm >> not imagining what exactly ends up being easier? >> >> But anyway, I guess it's a small detail. I'll review ignoring >> that. > > I was trying to reply and explain the logic behind my choice, but the > more I developed, the more I felt it was not really founded. > > My reasoning about the difference was the following: > > """ > In RSP, the size is there for GDB to tell the target "here is how much data > I am handing you". Its function is to describe the data found in the packet. > It's more there as a matter convenience, saying how much data follows, than > representing an amount of target memory units. > > In MI, the size is not describing the amount of data you are handing GDB. It > represents a size in the context of the memory of the target. > """ > > However, the paragraph about RSP doesn't make much sense. We are the ones > defining the protocol, so the field can mean whatever we want. If we want it > to be in target addressable memory units, then there is nothing that prevents > that. It just needs to be well documented. Also, I realize that writing memory > would be the only place where we would be talking about the target's memory in > bytes, so it's not so really consistent. > > About the "it is easier" part, I initially found that the common part of gdbserver > would be less encumbered with code related to this if those sizes were in bytes. > Namely, > > * decode_M_packet > * decode_X_packet > * write_inferior_memory > * read_inferior_memory > * code related to this in process_serial_event > > could just operate on bytes and work without knowledge of the addressable memory unit. > However, upon closer inspection, it seems like other functions will need to be aware > of it anyway, such as check_mem_read and check_mem_write. These two functions do > computations on addresses, so they need to have the length of the read/write in > addressable units and not bytes. If we do it for these two functions, then it's > not much more work to do it cleanly for the other functions as well. > > Here is a draft of how the changes would look like in gdbserver when using addressable > memory units. It's really not that bad I think. > > https://github.com/simark/binutils-gdb/commit/2ecb2f054a288053e3726e92fb6126dd4c782a15 > > So in the end, it might be more consistent to use addressable memory units everywhere > in the RSP, and not more complicated to implement. Of course, that's only for things > related to the target memory, things that fetch an XML file would still be in bytes. > > What is your opinion on this? > >>> >>> -> $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. >> >> Off hand, I thought of qCRC and qSearch:memory. The latter is >> more interesting: >> >> - Would you allow searching for an 1 8-bit byte pattern? > > Hmm I don't know. To be safe I'd say no. If we do, it means we need to > search with a granularity of a byte. What if you search for the pattern > 0x2345 in this memory: > > 0x100 0123 > 0x101 4567 > 0x102 89ab > 0x103 cdef > > Should there be a match that spans halves of two addresses? Unless we only > search with a byte granularity in the special case where the pattern is > one byte long? But then what about 3-bytes patterns? > > I think it's a lot of corner cases for not much value. I think it could be > enhanced later to support it if somebody needs it. > >> - So what length would you use for that one? Host byte >> or addressable units? > > Length here would be in addressable units. > >> Thanks, >> Pedro Alves >> > > Thanks, > > Simon Oh, and I acknowledged your comments in the individual patches, they are all clear, thanks a lot. Simon