"A word-aligned memory transfer mechanism is needed"

"A word-aligned memory transfer mechanism is needed"

[Jim Blandy]

The description of the 'm' packet in (gdb)Remote Serial Protocol says:

Neither gdb nor the stub assume that sized memory transfers are
assumed using word aligned accesses. FIXME: A word aligned memory
transfer mechanism is needed.

This mysterious admonition is repeated in the description of the
reply.  The text seems to date back to the original check-in of the
docs.

At first I assumed that this was trying to say that ADDR isn't
necessarily word-aligned.  I think that's worth stating clearly.

But then I realized that it might be trying to say that a read or
write of a word-sized value to a word-aligned memory location may not
be carried out by the stub using a word-sized access; it is free to
use the appropriate number of byte accesses.  In other words, this
packet doesn't provide the kind of control needed to access some
memory-mapped I/O devices.

Do folks agree that this is what that meant to say?  If we're not sure
what it means, we should take it out.

Re: "A word-aligned memory transfer mechanism is needed"

[Eli Zaretskii]

> 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.

Re: "A word-aligned memory transfer mechanism is needed"

[Daniel Jacobowitz]

On Tue, Nov 15, 2005 at 06:09:16AM +0200, Eli Zaretskii 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.

Same from me, also.

I agree that the argument to m/M does not need to be word aligned, and
that this is worth writing down; I'm not sure whether we need a
word-sized I/O interface, but I agree that if we grow one, it should
not use the same m/M packets.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: "A word-aligned memory transfer mechanism is needed"

[Paul Koning]

>>>>> "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