From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 79737 invoked by alias); 9 Apr 2015 15:39:13 -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 79720 invoked by uid 89); 9 Apr 2015 15:39:12 -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, 09 Apr 2015 15:39:11 +0000 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id E2.B6.17241.56A36255; Thu, 9 Apr 2015 10:37:57 +0200 (CEST) Received: from [142.133.110.232] (147.117.188.8) by smtp-am.internal.ericsson.com (147.117.188.98) with Microsoft SMTP Server id 14.3.210.2; Thu, 9 Apr 2015 11:39:06 -0400 Message-ID: <55269D1A.3080902@ericsson.com> Date: Thu, 09 Apr 2015 15:39:00 -0000 From: Simon Marchi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Eli Zaretskii CC: Subject: Re: [PATCH 0/7] Support reading/writing memory on architectures with non 8-bits bytes References: <1428522979-28709-1-git-send-email-simon.marchi@ericsson.com> <83d23dg1bd.fsf@gnu.org> In-Reply-To: <83d23dg1bd.fsf@gnu.org> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00340.txt.bz2 On 15-04-09 04:20 AM, Eli Zaretskii wrote: >> From: Simon Marchi >> CC: Simon Marchi >> Date: Wed, 8 Apr 2015 15:56:12 -0400 >> >> On such a system, memory is addressable in atomic chunks of 16-bits. On >> a "normal" system, you have 8 bits of data associated with each memory >> address: >> >> Address Data >> --------------- >> 0x1000 0xaa >> 0x1001 0xbb >> 0x1002 0xcc >> 0x1003 0xdd >> >> whereas on a system with 16-bits bytes, you have 16-bits of data per >> address: >> >> Address Data >> --------------- >> 0x1000 0xaaaa >> 0x1001 0xbbbb >> 0x1002 0xcccc >> 0x1003 0xdddd >> >> To support these systems, GDB must be modified to consider the byte size >> when reading/writing memory. This is what this first patch series is >> about. >> >> Also, on these systems, sizeof(char) == 1 == 16 bits. There is therefore >> many places related to types and values handling that need to be >> modified. This will be the subject of subsequent patch series. > > I wonder: wouldn't it be possible to keep the current "byte == 8 bits" > notion, and instead to change the way addresses are interpreted by the > target back-end? > > IOW, do we really need to expose this issue all the way to the higher > levels of GDB application code? Hi Eli, I don't think there is an elegant way of making this work without gdb knowing at least a bit about it. If you don't make some changes at one level, you'll end up needing to make the equivalent changes at some other level (still in gdb core). We tried a few different combinations, and I don't know of any where we don't need to touch the core of gdb at some point. I'd be happy to be proven wrong though! >From what I understand, your suggestion would be to treat addresses as indexes of octets in memory. So, to read target bytes at addresses 3 and 4, I would have to ask gdb for 4 "gdb" bytes starting at address 6. size == 2 v-------------------v +---------+---------+---------+---------+---------+---------+ real idx | 0 | 1 | 2 | 3 | 4 | 5 | +----+----+----+----+----+----+----+----+----+----+----+----+ octet idx | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | +----+----+----+----+----+----+----+----+----+----+----+----+ ^-------------------^ size == 4 The backend would then divide everything by two and read 2 target bytes starting at address 3. If we require the user or the front-end to do that conversion, we just push the responsibility over the fence to them. The interface will be quite poor and unintuitive. For the developer working with that system 8 hours per day, a size of 1 is one 16-bits byte. His debugger should understand that language. If I have a pointer p (char *p) and I want to examine memory starting at p, I would do "x/10h p". That wouldn't give me what I want, as it would give me memory at p/2. Also, the gdb code in the context of these platforms becomes instantly more hackish if you say that the address variable is not really the address we want to read, but the double. There are enough things in as it is to scare new gdb developers, we do not need any more :). Another problem: the DWARF information describes the types using sizes in target bytes (at least in our case, other implementations could do it differently I suppose). The "char" type has a size of 1 (1 x 16-bits). So, when you "print myvar", gdb would have to know that it needs to convert the size to octets to request the right amount of memory. I think the solution we propose is the one that models the best the debugged system and therefore is the least hacky. From a gdb development point of view, it makes things clear and explicit. Does this answer you concerns? Simon