Re: Interested in remote protocol improvements

Re: Interested in remote protocol improvements

[Daniel Jacobowitz]

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

AW: Interested in remote protocol improvements

[Sascha]

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.

Thanks

Sascha

AW: Interested in remote protocol improvements

[Sascha]

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.

Thanks

Sascha

AW: Interested in remote protocol improvements

[Sascha]

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.

Thanks

Sascha

AW: Interested in remote protocol improvements

[Sascha]

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.

Thanks

Sascha

AW: Interested in remote protocol improvements

[Sascha]

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.

Thanks

Sascha

AW: Interested in remote protocol improvements

[Sascha]

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.

Thanks

Sascha

AW: Interested in remote protocol improvements

[Sascha]

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.

Thanks

Sascha

AW: Interested in remote protocol improvements

[Sascha]

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.

Thanks

Sascha

AW: Interested in remote protocol improvements

[Sascha]

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.

Thanks

Sascha

AW: Interested in remote protocol improvements

[Sascha]

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.

Thanks

Sascha

AW: Interested in remote protocol improvements

[Sascha]

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.

Thanks

Sascha

AW: Interested in remote protocol improvements

[Sascha]

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.

Thanks

Sascha

AW: Interested in remote protocol improvements

[Sascha]

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.

Thanks

Sascha

AW: Interested in remote protocol improvements

[Sascha]

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.

Thanks

Sascha

AW: Interested in remote protocol improvements

[Sascha]

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.

Thanks

Sascha

AW: Interested in remote protocol improvements

[Sascha]

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.

Thanks

Sascha

AW: Interested in remote protocol improvements

[Sascha]

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.

Thanks

Sascha

AW: Interested in remote protocol improvements

[Sascha]

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.

Thanks

Sascha

AW: Interested in remote protocol improvements

[Sascha]

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.

Thanks

Sascha

AW: Interested in remote protocol improvements

[Sascha]

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.

Thanks

Sascha

AW: Interested in remote protocol improvements

[Sascha]

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.

Thanks

Sascha

Re: Interested in remote protocol improvements

['Daniel Jacobowitz']

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

Re: Interested in remote protocol improvements

[Sascha]

> 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.

> 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.

Somehow I feel that this is a Win32 issue, but I haven't found any
information about this (Maybe you (or someone else) can run the "while++ <
10000" test on windows using mingw gdb and gdbserver to verify this? )
I already noticed that there is a pipe support implemented for gdb/mingw -
is that what you are using ? Unfortunately there is no documentation. I had
a look at the source and did a test but GDB wants to launch another
application if I specify the "|" to use a pipe (target remote | something).
My stub is already running and it would use the named pipe api. Does gdb
support named pipes ?
 
> Gdbserver didn't used to be available, but it is now.  You can build it
> from the latest FSF HEAD snapshots;

Alright. Good to know.

Another question about the remote protocol... the error code numbers don't
have any effect, do they ? If my stub responds with "E99" for example,  how
do I notice this (number) in GDB ? And even more important, how do I notice
this using GDB/MI ?

Thanks

Re: Interested in remote protocol improvements

['Daniel Jacobowitz']

On Fri, Aug 04, 2006 at 05:39:16PM +0200, Sascha wrote:
> > 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.
> 
> > 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.
> 
> Somehow I feel that this is a Win32 issue, but I haven't found any
> information about this (Maybe you (or someone else) can run the "while++ <
> 10000" test on windows using mingw gdb and gdbserver to verify this? )

First I tried using mingw gdbserver and a stock Cygwin GDB:

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

So, that's about 0.5ms.  It's ten times worse than the 0.05ms I could
generate on GNU/Linux, but much better than you were seeing.  This is a
Dell laptop from last year; it's got a 1.6GHz Pentium M (though I think
it's power-managed down to something slower right now).

I also tried a native mingw32 GDB built from HEAD and got 5.788000
seconds; about the same really.

> I already noticed that there is a pipe support implemented for gdb/mingw -
> is that what you are using ? Unfortunately there is no documentation. I had

Sure there is:

`target remote | COMMAND'
     Run COMMAND in the background and communicate with it using a
     pipe.  The COMMAND is a shell command, to be parsed and expanded
     by the system's command shell, `/bin/sh'; it should expect remote
     protocol packets on its standard input, and send replies on its
     standard output.  You could use this to run a stand-alone simulator
     that speaks the remote debugging protocol, to make net connections
     using programs like `ssh', or for other similar tricks.

     If COMMAND closes its standard output (perhaps by exiting), GDB
     will try to send it a `SIGTERM' signal.  (If the program has
     already exited, this will have no effect.)
   
("Remote Debugging" chapter, under "Connecting").

> a look at the source and did a test but GDB wants to launch another
> application if I specify the "|" to use a pipe (target remote | something).
> My stub is already running and it would use the named pipe api. Does gdb
> support named pipes ?

GDB does not yet have any support for named pipes on Windows.  This
could be added, I suppose; I don't need it myself, though.

> Alright. Good to know.
> 
> Another question about the remote protocol... the error code numbers don't
> have any effect, do they ? If my stub responds with "E99" for example,  how
> do I notice this (number) in GDB ? And even more important, how do I notice
> this using GDB/MI ?

In general, there is no way to do this today.  I've spent some time
thinking about the general issue of communicating errors, but I
haven't got any plans on how to improve the situation.  Someone
needs to come up with a solid design for this.

-- 
Daniel Jacobowitz
CodeSourcery