Re: [PATCH] Don't print too much if remote_debug is on

[Luis Machado <lgustavo@codesourcery.com>]

On 11/30/2016 06:54 AM, Yao Qi wrote:
> On Tue, Nov 29, 2016 at 09:45:59AM -0600, Luis Machado wrote:
>> On 11/29/2016 09:38 AM, Yao Qi wrote:
>>> If we turn "remote debug" on and GDB does some vFile operations,
>>> a lot of things will be printed in the screen, which makes
>>> "remote debug" useless.
>>>
>>> This patch changes the code that we don't print messages if
>>> messages are too long, greater than 512.  Instead, print
>>> "Sending packet: $vFile:pread:5,3fff,e0d12#c4...Packet received: [16384 bytes omitted]".
>>
>> How about not printing binary data at all and instead print some
>> useful information about contents being sent? Like the number of
>> bytes and maybe how many still need to be read?
>
> In putpkt/getpkt, we don't know the data is binary or not, unless we
> pass an additional parameter to indicate this.  Then, we need to
> go through every calls to putpkt/getpkt, check the data is plain text
> or binary, so pass the right value to putpkt/getpkt.

Ah, that's unfortunate.

>
> The binary and plain data is mixed in the buffer in some packets, like
> "vFile:pwrite: fd, offset, data".  If we want to print
> "Sending packet: $vFile:pwrite:5,e0d12,[16384 bytes]#c4" in the debug
> output, we need to move the debugging output from buffer level to
> packet level.  I agree it is better than
> "Sending packet: [16384 bytes omitted]" which is what my patch does.
>
> We can omit the received packet if it is more than REMOTE_DEBUG_MAX_CHAR
> chars; if the sent packet is more than REMOTE_DEBUG_MAX_CHAR chars, only
> print the first 50 chars, and omit the rest of them, so the debug
> output is like,
>
> Sending packet: $vFile:pread:5,3fff,e0d12#c4...Packet received: [16384 bytes omitted]
> Sending packet: $vFile:pwrite:5,e0d12,xxxyyyzzz[384 bytes omitted] ... Packet received: 358
>
> What do you think?
>

I think it is an improvement nonetheless. Personally i still find 
particular lengthy replies useful, like the XML descriptions. But all 
the binary data is too distracting, hence why i was suggesting only 
binary streams being restricted.

I'm fine with your version.