Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Paul Koning <pkoning@equallogic.com>
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"
Date: Tue, 15 Nov 2005 14:53:00 -0000	[thread overview]
Message-ID: <17273.63064.316612.231713@gargle.gargle.HOWL> (raw)
In-Reply-To: <20051115043448.GA12583@nevyn.them.org>

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> 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
 >> <jimb@red-bean.com>
 >> > 
 >> > 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


      reply	other threads:[~2005-11-15 14:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-15  2:59 Jim Blandy
2005-11-15  4:09 ` Eli Zaretskii
2005-11-15  4:34   ` Daniel Jacobowitz
2005-11-15 14:53     ` Paul Koning [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=17273.63064.316612.231713@gargle.gargle.HOWL \
    --to=pkoning@equallogic.com \
    --cc=drow@false.org \
    --cc=eliz@gnu.org \
    --cc=gdb@sources.redhat.com \
    --cc=jimb@red-bean.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox