This is the mail archive of the
mailing list for the GDB project.
AW: Interested in remote protocol improvements
- From: "Sascha" <sascha at pasalacqua dot de>
- To: "'Daniel Jacobowitz'" <drow at false dot org>
- Cc: <gdb at sourceware dot org>
- Date: Sat, 29 Jul 2006 16:11:59 +0200
- Subject: AW: Interested in remote protocol improvements
Thanks for your reply.
>What I need is for people with
>additional problems to tell us more about them, so that we can
>cooperate on improving it.
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.
>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. Maybe the 'g' packet will fetch
all registers. I haven't tried that yet as I didn't want all registers to be
transmitted. Some registers need special processing (and are not required
for gdb's stack processing, etc.) so it takes a bit more time which slows
down the step process (mentioned above). But I'm going to try to respond
with signal packet which includes all base registers. All additional (+
base) registers could be received by 'g' then.
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.
>>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.
>>As for localhost communications, 5-10ms seems high. What platform is
>>this? How long does this test take?
>>Command execution time: 0.422936
This is quite scary: about 60 seconds ! So this would be about 6ms for
request+reply. It's a bit less if both processes have high priority.
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?). 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.