remote protocol extension for memory region attributes

[Andrew Cagney]

"J.T. Conklin" wrote:
> 
> The remote protocol's memory read and write commands need to be
> extended to handle target-side memory region attributes.
> 
> All but one of the attributes I've implemented so far are handled
> entirely within GDB.  At this time, only access-width needs to be
> passed to the target.  However, any protocol change made now shouldn't
> preclude future target-side attributes, as the facility is intended to
> be extensible.
> 
> My current thought is to add attributes to the 'm' and 'M' commands.
> 
> The memory read command would become:
> 
>         mAA..AA,LLLL[,attribute=<value>[,...]]
> 
> The memory write command would become:
> 
>         MAA..AA,LLLL[,attribute=<value>[,...]]:XX...XX
> 
> The problems with this approach are:
> 
> * In general, the sample stubs aren't very strict about validating
>   commands.  In this case, the memory read command does not report an
>   error if any characters follow the length.  This makes it difficult
>   if not impossible to detect whether a target supports attributes, as
>   they will be silently ignored.

The only alternative here is to steal another letter :-(  Alternativly,
by default disable the mechanism and then warn the user if it is
suspected that the target doesn't support it.

> * The payload length is decreased.

Not a real problem.  Most targets support fairly large packet sizes so
they are not going to notice a small loss in payload size.

> These problems could be solved by having a separate command that would
> set the attributes to be used for future reads and writes, like is
> done for threads, but this adds state to the stub (IMO not a problem,
> considering the state required for target managed breakpoints); and
> more importantly it adds latency since two commands would have to be
> sent instead of one.
> 
> I'm inclined to live with the defects and go with extending the
> existing commands.

Yes.  I think it is more important to have commands that are fairly
independant.  Besides, with 500ms round trip times, the less
transactions the better.

	Andrew