This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: remote protocol extension for memory region attributes
- To: jtc at redback dot com
- Subject: Re: remote protocol extension for memory region attributes
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Wed, 01 Nov 2000 23:35:18 +1100
- Cc: gdb at sourceware dot cygnus dot com
- References: <5m7l9jcvxp.fsf@jtc.redback.com>
"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