This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]