This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Make remote transfers interruptible
- From: Sandra Loosemore <sandra at codesourcery dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Gary Benson <gbenson at redhat dot com>, <gdb-patches at sourceware dot org>, Doug Evans <dje at google dot com>
- Date: Mon, 17 Aug 2015 12:52:40 -0600
- Subject: Re: [PATCH] Make remote transfers interruptible
- Authentication-results: sourceware.org; auth=none
- References: <55C3A10F dot 3010106 at codesourcery dot com> <1439389814-29211-1-git-send-email-gbenson at redhat dot com> <55CB8300 dot 3060004 at codesourcery dot com> <55D20502 dot 4070500 at redhat dot com>
On 08/17/2015 10:00 AM, Pedro Alves wrote:
I was previously assuming you were seeing this on multiple machines,
but looking back, I only find mention of nios2.
Could it be the slowdown you see is caused by some other local patches
you might have in the tree you're using? Do you see it with pristine FSF?
I initially saw this in a local branch, but I have been very careful to
reproduce and test things with an unmodified FSF checkout.
If you try your example test with gdb 7.9, with "set sysroot remote:",
does it also take the 4 minutes to reach main?
Also, can you reproduce this with other machines? E.g., what about
x86_64 GNU/Linux? Wondering whether it's a kernel/libc/etc issue...
The other Linux-target build I have handy for testing right now is
arm-none-linux-gnueabi with unmodified FSF head, testing on a
PandaBoard. There I found it takes about 8 seconds to start up the same
hello-world program that takes 4 minutes on Nios II with the new sysroot
default, and < 1 second if I do "set sysroot" first. Aside from
possible kernel issues or whatever, the Nios II board is theoretically a
factor of 20 slower than the PandaBoard (processor supposedly clocked at
10Mhz, and only one core versus 1Ghz and 2 cores for the PandaBoard),
and the libc.so it's transferring is larger.
-Sandra