From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4407 invoked by alias); 15 Nov 2005 14:53:22 -0000 Received: (qmail 4398 invoked by uid 22791); 15 Nov 2005 14:53:17 -0000 Received: from sadr.equallogic.com (HELO sadr.equallogic.com) (66.155.203.134) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 15 Nov 2005 14:53:17 +0000 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id jAFErEVH013622 for ; Tue, 15 Nov 2005 09:53:15 -0500 Received: from M31.equallogic.com (M31.equallogic.com [172.16.1.31]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id jAFErETt013617; Tue, 15 Nov 2005 09:53:14 -0500 Received: from pkoning.equallogic.com ([172.16.1.193]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Nov 2005 09:53:14 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17273.63064.316612.231713@gargle.gargle.HOWL> Date: Tue, 15 Nov 2005 14:53:00 -0000 From: Paul Koning To: drow@false.org Cc: eliz@gnu.org, jimb@red-bean.com, gdb@sources.redhat.com Subject: Re: "A word-aligned memory transfer mechanism is needed" References: <8f2776cb0511141858x1e140278vdfe58bc3efee2a6@mail.gmail.com> <20051115043448.GA12583@nevyn.them.org> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2005-11/txt/msg00296.txt.bz2 >>>>> "Daniel" == Daniel Jacobowitz writes: Daniel> On Tue, Nov 15, 2005 at 06:09:16AM +0200, Eli Zaretskii Daniel> wrote: >> > Date: Mon, 14 Nov 2005 18:58:56 -0800 > From: Jim Blandy >> >> > >> > Do folks agree that this is what that meant to say? If we're >> not sure > what it means, we should take it out. >> >> I'm not familiar with history, but your conclusions sound >> plausible. Daniel> Same from me, also. Daniel> I agree that the argument to m/M does not need to be word Daniel> aligned, and that this is worth writing down; I'm not sure Daniel> whether we need a word-sized I/O interface, but I agree that Daniel> if we grow one, it should not use the same m/M packets. In debugging embedded systems, from time to time you find yourself wanting to touch CSRs. If you trust GDB and the remote stub to "do what I want" you can use regular memory access mechanisms, at least some of the time. The access sizes *should* be what the commands imply -- if you can trust that. (Can you?) This may or may not work for 8-byte accesses, and I've run into CSRs that must be accessed with long long loads/stores. Another issue is that CSRs may be write-only, so a store operation that does a load along the way will break. Bottom line: the m/M mechanisms are defined to act on memory; essentially they are remote memcpy() operations with arbitrary starting alignment and arbitrary byte count. It would be useful to have a set of GDB commands that have rigorously defined semantics that make them work for CSR accesses, with corresponding remote protocol commands. At first approximation, that would be loads and stores of naturally aligned 1, 2, 4, and 8 byte objects, where each is defined to be a single action. For example, a store must be *only* a store, not a load then store. And either access must be a single operation; if the target doesn't have native 8-byte operations, the 8 byte accesses must be rejected, not synthesized out of two 4-byte ops. paul