This is the mail archive of the gdb-patches@sourceware.org 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]
Other format: [Raw text]

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


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.


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