Re: Interested in remote protocol improvements

['Daniel Jacobowitz' <drow@false.org>]

On Sat, Jul 29, 2006 at 04:11:59PM +0200, Sascha wrote:
> I'll probably come up with some more problems when I work on the stub again.
> Something I'd be really interested in is the "step-range" packet you
> mentioned before. On a remote target stepping a C/C++ instruction can take
> some time as GDB fires a lot of step packets.

Yes, this is important.

> >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.
> 
> It's the latest code sourcery arm-eabi-gdb.

I rewrote a bunch of the native Windows support code after our last release.
I bet that would help you with your networking performance problems. 
None of that code is on the branch; it's only available on the FSF
HEAD, which doesn't have the XML description stuff yet.

You probably can't use HEAD to debug your target, but do you want to
try building it and repeating the simple performance test?

> Maybe a small bug: The first time I replied to the 'g' packet with all
> standard arm registers (r.., f.., cpsr). But then GDB did NOT fetch the
> other registers using the 'p' packet. Instead it just reported the
> additional registers defined in target.xml as 0. Then I left out some
> registers (like cpsr) in the 'g' packet and it worked.

Things will get messed up if you put registers in your g packet that
aren't in the XML description.  This isn't adequately clear in the
documentation yet; I'll be fixing that before the submission to
mainline.

> >>For memory, you can tell GDB to cache 16-byte or 32-byte "cache lines".
> >>That may boost disassembly performance.  See "help mem".
> 
> I remember this caused some trouble with my stub. I will have to fix that
> first. I also was not sure how this would affect "volatile" memory like the
> arm memory-mapped regs.

You have to manually mark them as not cached.

> Platform is Windows(XP,SP2) running on Mobile Athlon XP 1700 and Code
> Sourcery arm-none-eabi-GDB connected to local stub (my own stub, gdbserver
> is not available for win32?).

Gdbserver didn't used to be available, but it is now.  You can build it
from the latest FSF HEAD snapshots; I do it by running the configure
script directly in the gdb/gdbserver/ subdirectory, from a Cygwin
shell, with CC set to "gcc -mno-cygwin".  And be sure to pass
--host=i686-mingw32 to configure.

> I tried to write a simple ping-pong tcp
> client/server app to test the maximum performance and the best result I got
> was 2 ms for a request/reply which is still way more than 0.05ms as
> mentioned by you using linux. So does anyone know if this is a win32 issue?
> Disabling nagle does not seem to help either.

It might be a general Windows issue... but that would be pretty
disappointing.  If it is, there's not much we can do about it :-(
You might want to try communicating with the stub over a pipe instead
of a TCP socket; that's what we've been doing recently here at
CodeSourcery.

-- 
Daniel Jacobowitz
CodeSourcery