This is the mail archive of the
mailing list for the GDB project.
remote protocol extension for memory access width
- To: gdb at sourceware dot cygnus dot com
- Subject: remote protocol extension for memory access width
- From: jtc at redback dot com (J.T. Conklin)
- Date: 25 Jan 2001 18:01:09 -0800
- Reply-To: jtc at redback dot com
Ok, now that the memory attribute code is in and we're working out the
kinks, I'm going to try to nail down the remote protocol extension to
pass the access width to the debug agent.
The current memory read and write commands take the form:
mAA..AA,LLLL Read LLLL bytes at address AA..AA
MAA..AA,LLLL:DDDD.. Write LLLL bytes at address AA..AA
Rather than add new commands, my thought is to add attribute support
This leaves the format open for additional attributes to be added in
the future. Although this reduces the maximum payload of the memory
write command, I don't think it's significant enough to matter. The
user presumably needs the attributes, otherwise s/he wouldn't have
For memory access width, I propose using "width=X", where X is 8, 16,
32, or 64. If no access width was specified (MEM_WIDTH_UNSPECIFIED),
no attribute would be appended to the commands.
I think the above is not controversial, but there are some issues that
I need some assistance working out.
* At present, there is nothing that ensures that an address and length
passed to target_xfer_memory() are aligned to a access width boundry.
IMHO it would be wrong to change this: target_xfer_memory() provides
an abstraction layer between GDB's upper and lower layers. But this
implies that either within or somewhere below target_xfer_memory() we
must handle misaligned transfer addresses and sizes.
* What does "handling" missaligned transfers entail? IMO, this means
that only part of the first and/or last "word" of a transfer may be
required to complete the transfer. This would require the whole
word to be transfered, but only the needed byte(s) would copied to
* So at what layers should this occur? One approach is to require the
debug agent to handle it itself. This is how I've been prototyping
the facility. But I have a couple of problems with it. IMHO it is
making a too large assumption about the capabilities of the target.
We can get away with it with the remote protocol, since we control
both ends. But we shouldn't preclude using this with other back
ends. The SingleStep debugger has a similar facility, so if we ever
got a hold of a SDS protocol description we should be able to support
Even if we were to stick with only the remote protocol, I'm having a
hard time reconciling the protocol's lean-and-mean design philosophy
with the requirement that it handle misaligned accesses. I would be
comfortable with the idea that the debug agent could reject them out
of hand. However, I think I could probably be convinced otherwise.
For example, the protocol was once stateless...
* So if we can't leave it to the remote systems, we could require it
to be handled by the target vector xfer_memory functions. This is
distasteful to me because it requires support code to be added to
* This leads me to believe any misalignment handling should be done
above the target layer. This could be done in do_xfer_memory(),
which sits below both target_xfer_memory() and the code that reads
and writes a dcache line. (although, since a cache line has greater
alignment than can be specified by a memory attribute, it will not
need any special handling).
For the remote protocol, I'm currently thinking that the protocol
extension be written up such that GDB "MUST" send a memory read/write
Please share your thoughts, as I'm actively finishing up this feature.