Re: [PATCH] remote_rcmd

Re: [PATCH] remote_rcmd

[Andrew Cagney]

> Hi,
> 
> This small patch adds support for receving more that ~200 bytes
> of output from the "qRcmd" request (ie the monitor command).
> 
> I have no idea if this will break any stubs, but hopefully not.
> I don't know how often stubs implement the qRcmd request.
> 
> 2002-06-27  Johan Rydberg  <jrydberg@rtmk.org>
> 
>         * remote.c (remote_rcmd): Continue reading output from
>         stub until receiving OK.

If I understand this patch correctly, it is changing things so that it 
allows:

	-> rCmd <command>
	<- <HEX-OUTPUT>
	<- <HEX-OUTPUT>
	<- OK

This is wrong.  The target should send:

	-> rCmd <command>
	<- O <HEX-OUTPUT>
	<- O <HEX-OUTPUT>
	<- OK

when transfering a longer buffer.

Andrew

> Index: remote.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/remote.c,v
> retrieving revision 1.87
> diff -u -u -r1.87 remote.c
> --- remote.c	15 Jun 2002 22:05:32 -0000	1.87
> +++ remote.c	27 Jun 2002 01:42:02 -0000
> @@ -5210,7 +5210,6 @@
>  	  char c = (fromhex (p[0]) << 4) + fromhex (p[1]);
>  	  fputc_unfiltered (c, outbuf);
>  	}
> -      break;
>      }
>  }
> 

Re: [PATCH] remote_rcmd

[Daniel Jacobowitz]

On Sun, Jul 14, 2002 at 12:31:31PM -0400, Andrew Cagney wrote:
> >Hi,
> >
> >This small patch adds support for receving more that ~200 bytes
> >of output from the "qRcmd" request (ie the monitor command).
> >
> >I have no idea if this will break any stubs, but hopefully not.
> >I don't know how often stubs implement the qRcmd request.
> >
> >2002-06-27  Johan Rydberg  <jrydberg@rtmk.org>
> >
> >        * remote.c (remote_rcmd): Continue reading output from
> >        stub until receiving OK.
> 
> If I understand this patch correctly, it is changing things so that it 
> allows:
> 
> 	-> rCmd <command>
> 	<- <HEX-OUTPUT>
> 	<- <HEX-OUTPUT>
> 	<- OK
> 
> This is wrong.  The target should send:
> 
> 	-> rCmd <command>
> 	<- O <HEX-OUTPUT>
> 	<- O <HEX-OUTPUT>
> 	<- OK
> 
> when transfering a longer buffer.

Actually, the current docs suggest:

-> qRcmd command
<- O <HEX-OUTPUT>
<- O <HEX-OUTPUT>
<- <HEX-OUTPUT>
<- OK

which confuses me.  What's supposed to differentiate the O <HEX-OUTPUT>
packets from the final <HEX-OUTPUT> packet (what difference in purpose,
I mean)?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [PATCH] remote_rcmd

[Andrew Cagney]

> 
> Actually, the current docs suggest:
> 
> -> qRcmd command
> <- O <HEX-OUTPUT>
> <- O <HEX-OUTPUT>
> <- <HEX-OUTPUT>
> <- OK

Where?

> which confuses me.  What's supposed to differentiate the O <HEX-OUTPUT>
> packets from the final <HEX-OUTPUT> packet (what difference in purpose,
> I mean)?

Valid replies to ``qRcmd'' are:

	``OK''
	``''
	``<HEX-OUTPUT>''
	``Enn''

The ``O'' packet is something separate.

Andrew

Re: [PATCH] remote_rcmd

[Daniel Jacobowitz]

On Sun, Jul 14, 2002 at 01:48:38PM -0400, Andrew Cagney wrote:
> >
> >Actually, the current docs suggest:
> >
> >-> qRcmd command
> ><- O <HEX-OUTPUT>
> ><- O <HEX-OUTPUT>
> ><- <HEX-OUTPUT>
> ><- OK
> 
> Where?

                              COMMAND (hex encoded) is passed to the
                              local interpreter for execution.  Invalid
                              commands should be reported using the
                              output string.  Before the final result
                              packet, the target may also respond with
                              number of intermediate `O'OUTPUT console
                              output packets.

...

               reply OUTPUT   A command response with the hex encoded
                              output string OUTPUT.

> >which confuses me.  What's supposed to differentiate the O <HEX-OUTPUT>
> >packets from the final <HEX-OUTPUT> packet (what difference in purpose,
> >I mean)?
> 
> Valid replies to ``qRcmd'' are:
> 
> 	``OK''
> 	``''
> 	``<HEX-OUTPUT>''
> 	``Enn''
> 
> The ``O'' packet is something separate.

I think I wasn't clear in my question.  qRcmd can send some O packets,
which are supposed to provide some ambiguous form of "output" from the
"console", and then one <HEX-OUTPUT> packet.  What is supposed to go in
which?  It doesn't make sense to me to limit this to one <HEX-OUTPUT>
packet if it is arbitrary output; it may simply be too large.  On the
other hand I'm not sure I see why both O<HEX> and <HEX> are allowed.


-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [PATCH] remote_rcmd

[Andrew Cagney]

> On Sun, Jul 14, 2002 at 01:48:38PM -0400, Andrew Cagney wrote:
> 
>> >
>> >Actually, the current docs suggest:
>> >
>> >-> qRcmd command
>> ><- O <HEX-OUTPUT>
>> ><- O <HEX-OUTPUT>
>> ><- <HEX-OUTPUT>
>> ><- OK
> 
>> 
>> Where?
> 
> 
>                               COMMAND (hex encoded) is passed to the
>                               local interpreter for execution.  Invalid
>                               commands should be reported using the
>                               output string.  Before the final result
>                               packet, the target may also respond with
>                               number of intermediate `O'OUTPUT console
>                               output packets.

``before the final _result_ packet''

> ...
> 
>                reply OUTPUT   A command response with the hex encoded
>                               output string OUTPUT.

This is one of several ``_result_'' packets.

>> >which confuses me.  What's supposed to differentiate the O <HEX-OUTPUT>
>> >packets from the final <HEX-OUTPUT> packet (what difference in purpose,
>> >I mean)?
> 
>> 
>> Valid replies to ``qRcmd'' are:
>> 
>> 	``OK''
>> 	``''
>> 	``<HEX-OUTPUT>''
>> 	``Enn''
>> 
>> The ``O'' packet is something separate.
> 
> 
> I think I wasn't clear in my question.  qRcmd can send some O packets,
> which are supposed to provide some ambiguous form of "output" from the
> "console", and then one <HEX-OUTPUT> packet.  What is supposed to go in
> which?  It doesn't make sense to me to limit this to one <HEX-OUTPUT>
> packet if it is arbitrary output; it may simply be too large.  On the
> other hand I'm not sure I see why both O<HEX> and <HEX> are allowed.

Sorry, you've lost me.  There are a number of choices and which is used 
is left to the implementor.  Sequences like:

	<- O output
	<- O output
	<- OK
and
	<- O output
	<- output
and
	<- output
and
	<- OK

are all valid.  To be honest, I've only seen targets use the last two. 
Typically the command response is so small that it can be safely 
squeesed into a single reply packet.

Andrew

Re: [PATCH] remote_rcmd

[Johan Rydberg]

On 2002.07.14 20:28 Andrew Cagney wrote:

: > I think I wasn't clear in my question.  qRcmd can send some O packets,
: > which are supposed to provide some ambiguous form of "output" from the
: > "console", and then one <HEX-OUTPUT> packet.  What is supposed to go in
: > which?  It doesn't make sense to me to limit this to one <HEX-OUTPUT>
: > packet if it is arbitrary output; it may simply be too large.  On the
: > other hand I'm not sure I see why both O<HEX> and <HEX> are allowed.

If I'm not mistaken, the "O"-packet is used for just transfering one
character, not a string.

: Sorry, you've lost me.  There are a number of choices and which is used 
: is left to the implementor.  Sequences like:
: 
: 	<- O output
: 	<- O output
: 	<- OK
: and
: 	<- O output
: 	<- output
: and
: 	<- output
: and
: 	<- OK
: 
: are all valid.  To be honest, I've only seen targets use the last two. 
: Typically the command response is so small that it can be safely 
: squeesed into a single reply packet.

Typically it can squeese into one packet, yes.  But should the protocol
really put a limit on the output?

regards
johan

Re: [PATCH] remote_rcmd

[Andrew Cagney]

> On 2002.07.14 20:28 Andrew Cagney wrote:
> 
> : > I think I wasn't clear in my question.  qRcmd can send some O packets,
> : > which are supposed to provide some ambiguous form of "output" from the
> : > "console", and then one <HEX-OUTPUT> packet.  What is supposed to go in
> : > which?  It doesn't make sense to me to limit this to one <HEX-OUTPUT>
> : > packet if it is arbitrary output; it may simply be too large.  On the
> : > other hand I'm not sure I see why both O<HEX> and <HEX> are allowed.
> 
> If I'm not mistaken, the "O"-packet is used for just transfering one
> character, not a string.

The ``O'' packet takes a string.

> : Sorry, you've lost me.  There are a number of choices and which is used 
> : is left to the implementor.  Sequences like:
> : 
> : 	<- O output
> : 	<- O output
> : 	<- OK
> : and
> : 	<- O output
> : 	<- output
> : and
> : 	<- output
> : and
> : 	<- OK
> : 
> : are all valid.  To be honest, I've only seen targets use the last two. 
> : Typically the command response is so small that it can be safely 
> : squeesed into a single reply packet.
> 
> Typically it can squeese into one packet, yes.  But should the protocol
> really put a limit on the output?

Should it?  Probably not (but it does).

> regards
> johan

Andrew