Re: GDB Proto: Draft revised spec...

[jtc@redback.com (J.T. Conklin)]

>>>>> "Todd" == Todd Whitesel <toddpw@wrs.com> writes:
jtc> 'm' and 'M': Should probably mention that there is no alignment or
jtc> width guarantees on either side.  GDB cannot assume a word sized
jtc> read/write command will be performed with word sized access;
jtc> likewise the stub cannot assume a word sized command will be word
jtc> aligned, etc, etc, etc.

Todd> It would be a Very Good Thing to have some set of commands for
Todd> forcing the size/alignment of an access. Every now and then
Todd> somebody has to debug code that uses the VME bus (which is
Todd> access size sensitive) or peripherals that are only decoded
Todd> properly when the right access size is used.

I have no doubts there needs to be protocol support for memory access
of given size/alignment.  I've run into this problem myself.  But I'd
rather have the definitive specification for the existing RDP before
proposing any more commands.

Todd> For a user to view pointer/struct variables that map to this
Todd> hardware, GDB needs to be able to recognize a "volatile" thing
Todd> somehow and force the accesses to be simple and unoptimized, or
Todd> provide some other method. 

I've been thinking of some sort of mechanism such that the user could
tag memory regions to disable dcache, force access widths, etc. so it
would not be necessary to have commands for specific sized or aligned
memory accesses and so the memory accesses made by GDB as part of more
complicated commands (walking stacks, etc.) could be made to work as
expected.  But if GDB could make the same decisions based on the
volatile qualifier it would be much better (and transparent too boot).

Todd> There are actual customers out there who use GDB to get the
Todd> address of something and then type that into another tool which
Todd> is able to control the access size on the target.

Painful.  I can sympathize.

Todd> This is a general problem with embedded debuggers; when I was at
Todd> Green Hills I added some little hacks to MULTI so that we could
Todd> support this on at least a few targets.


>> * The 'A' command seems out of place.  Program arguments are an
>> awfully high level concept for a low level protocol.

Todd> Not if your target is another unix machine. Does gdbserver use
Todd> this protocol?

No. Gdbserver supplies any arguments to be used by the program to be
debugged.  

Another problem with the 'A' command is that the size of the argument
list is constrained by the maximum size of the packet.

	--jtc

-- 
J.T. Conklin
RedBack Networks