This is the mail archive of the gdb@sources.redhat.com 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]

remote protocol extension for memory access width


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 
like:
        mAA..AA,LLLL[,attr=val[,attr=val[,...]]]
        MAA..AA,LLLL[,attr=val[,attr=val[,...]]]:DDDD...

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

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

* 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
  it there.  

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

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

Please share your thoughts, as I'm actively finishing up this feature.

        --jtc

-- 
J.T. Conklin
RedBack Networks

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