Re: Interested in remote protocol improvements

[Daniel Jacobowitz <drow at false dot org>]

On Fri, Jul 28, 2006 at 05:36:38PM +0200, Sascha wrote:
> Hi,
> 
> I read some posts from Daniel Jacobowitz and his plans about improving the
> remote protocol. Are there any further informations available?

Pretty much all of the projects I've got in progress I've been
discussing on the mailing lists.  What I need is for people with
additional problems to tell us more about them, so that we can
cooperate on improving it.

> I already tested the "Self-describing targets" target.xml idea and it works
> pretty well (using the codesourcery gdb for arm). I used the target
> description to add new registers - this way I could avoid hacking GDB.

That's great news!  I'm glad to hear that it was useful.

The protocol as implemented on that branch is never going to be merged.
However, something will be, and I hope it won't be too different.  I've
been waiting on this because it overlaps with the flash memory patches
that my coworked Vladimir has been submitting.  I hope we'll be done
merging those in another week or two; after that, I'll be focusing on
this project again.

> Since my current project depends on the remote protocol performance I'm
> interested in any progress.
> The biggest problem is the speed. Even on my localhost tcp connection a
> request + reply packet takes about 5-10 ms. So if GDB is driven by some
> external IDE which fetches all registers and maybe some disassembly after
> each step/break you can easily reach 1 second delay for every step.
> Unfortunately GDB tries to fetch every additional register one by one using
> the P packet. The same thing happens for the disassembly (word by word).

Where does the GDB you're using come from?  I thought that I had fixed
CodeSourcery's to use the 'g' packet for any registers which are
available that way.  This isn't documented yet, but that version of GDB
will just decode bytes in the 'g' packet in the same order as the
"protocol numbers" from the target XML descriptions.  So one option is
to enlarge your 'g' packet.

I know this doesn't work in FSF GDB.  If 'p' is present it will be used
exclusively for all registers.  That's one of the bits I need to
submit.

Another possible improvement would be to add a "fetch list of
registers" packet.  But this is very hard to integrate with the way GDB
works now; we don't know early enough which registers will be
necessary.  I'm not sure how to approach this but it would be a lot of
work.

For memory, you can tell GDB to cache 16-byte or 32-byte "cache lines".
That may boost disassembly performance.  See "help mem".

As for localhost communications, 5-10ms seems high.  What platform is
this?  How long does this test take?

(gdb) maint time 1
(gdb) set $i = 0
(gdb) while $i++ < 10000
 >set $b = *(char *)$pc
 >end
Command execution time: 0.422936

That's about 0.05 ms per packet + response.  This is GNU/Linux,
connected to a gdbserver running on localhost.

-- 
Daniel Jacobowitz
CodeSourcery