From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4738 invoked by alias); 29 Jun 2004 20:40:35 -0000 Mailing-List: contact sid-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: sid-owner@sources.redhat.com Received: (qmail 4690 invoked from network); 29 Jun 2004 20:40:35 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 29 Jun 2004 20:40:35 -0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i5TKeYe1016967 for ; Tue, 29 Jun 2004 16:40:34 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i5TKeSw08080 for ; Tue, 29 Jun 2004 16:40:28 -0400 Received: from redhat.com (to-dhcp15.toronto.redhat.com [172.16.14.115]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i5TKeRP17625; Tue, 29 Jun 2004 13:40:27 -0700 Message-ID: <40E1D329.1060705@redhat.com> Date: Tue, 29 Jun 2004 20:40:00 -0000 From: Dave Brolley User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) MIME-Version: 1.0 To: "Frank Ch. Eigler" CC: sid@sources.redhat.com Subject: Re: Misaligned read/write of memory by GDB References: <40E08B13.7000404@redhat.com> <40E0A0B0.3020001@redhat.com> <20040629182721.GK10148@redhat.com> <40E1BEF2.4070401@redhat.com> <20040629191821.GM10148@redhat.com> In-Reply-To: <20040629191821.GM10148@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-q2/txt/msg00058.txt.bz2 Frank Ch. Eigler wrote: >>I thought about the possibility of fixing existing memory targets to >>handle misaligned access, either by implementing support, returning >>sid::bus::misaligned, or whatever else might be appropriate. >> >> > >How many offenders (that did neither) did you encounter? > Just one. The cache component. It silently reads directly from the backing memory, thus (potentially) returning the wrong value. >>However it occurred to me that this would require implementors of all >>future memory targets to be aware of potential GDB access of this >>type. [...] >> >> > >True, except that such accesses could originate elsewhere - a simulated >CPU, or a gloss component, for example. > > I guess one could argue that all complete component implementations should handle all possible input possibilities. The failure was not obvious in my case because of the silent misbehavior of the cache component. I guess I was just wanting to prevent a similar misfortune from happening to someone else (or me again!) in the future. Your gloss example convinces me that the cache component should be fixed, however. Once done, I can implement the GDB access in the way you've suggested. Dave