Re: [PATCH] Prelimit number of bytes to read in "vFile:pread:"

[Sandra Loosemore <sandra at codesourcery dot com>]

On 08/19/2015 11:20 AM, Gary Benson wrote:
> Sandra Loosemore wrote:
> > On 08/19/2015 04:50 AM, Gary Benson wrote:
> > > Sandra, could you please try this patch on your Altera 3c120 and
> > > on your PandaBoard?  I'm interested to know what the times are
> > > now.
> >
> > Wow, this patch made a big improvement!  On the nios2 board the
> > startup took 18 seconds the first time and 10 seconds on subsequent
> > attempts -- probably some NFS-level caching?  On the PandaBoard it
> > was 3 seconds or less.
>
> Great :)  It's in master and 7.10 now.
>
> Could you try Pedro's readahead patch too?  It's the third one here:
>
> https://sourceware.org/ml/gdb-patches/2015-08/msg00489.html
>
> Maybe with the readahead_cache_invalidate in
> remote_hostio_set_filesystem removed?  I'm interested to see if that
> helps any.  You don't need the other two patches in that message.

This didn't do anything to help; the startup time is still 10-11 seconds.

> > On 08/19/2015 07:42 AM, Gary Benson wrote:
> > > Pedro Alves wrote:
> > > > BTW, the transfers seem to be always interruptible for me, even
> > > > without Gary's patch, and even the slow ones.
> > >
> > > Ok, I'm glad I'm not the only one :)
> >
> > Unfortunately, I still can't see that ^C is doing anything useful
> > for me.  It is not coming back to a gdb prompt any sooner and "info
> > sharedlibrary" afterwards prints the same thing whether or not I've
> > tried to interrupt it.  This was with unpatched FSF trunk.  How am I
> > supposed to tell whether ^C did anything?  How are you guys telling
> > that it is doing something useful?  Is there supposed to be some
> > sort of message?  If the file transfer from the target is aborted, I
> > think it should say that.
>
> It stops immediately when I try it.  I'm not familiar with ^C handling
> either, so I don't know what would affect it.  Pedro, could this be
> a sync/async thing, or something to do with all-stop/non-stop?

Well, here is a clue.  I tried logging the RSP traffic so I could 
compare the interrupted and non-interrupted behavior.  Aside from 
differences in PID numbers (etc), the *only* difference is that the log 
from the interrupted run shows that it's sending a \x03 character to the 
remote target after it does a vCont, after it has already read the 
entire contents of libc.so.  Here's the relevant snippet from the 
transcript:

w $vFile:pread:5,3fff,b77987#e0
r $F3fca; [...]
w $qSymbol::#5b
r $qSymbol:6e70746c5f76657273696f6e#13
w $qSymbol::6e70746c5f76657273696f6e#4d
r $OK#9a
w $m2760,4#9c
r $fa6f3b00#58
w $m2ab0374c,4#f3
r $04fcffde#c2
w $m2ab0374c,4#f3
r $04fcffde#c2
w $m2ab0374c,4#f3
r $04fcffde#c2
w $m2aab6d98,4#2e
r $fa6f3b00#58
w $m2aab6d94,4#2a
r $3ae83e10#2a
w $X2aab6d98,4::(\x00\xf8#ad
r $OK#9a
w $m2aab6d98,4#2e
r $3a2800f8#fc
w $g#67
r $0*,2c84ac2a4084ac2a0*-10**58020100986dab2a0866aa2a030*"9a080* 
1c70ac2a3ceab42
a84b7c22a0*"004084ac2a8883ac2a4084ac2a646eac2a487bac2a0070ac2a3827c32a0*4f8f6fe7
f98f7fe7f986dab2a0*"00d0b1aa2a986dab2a0*}0*;#15
w $m2aaab1d0,4#49
r $17a082b0#f5
w $m2aaab1d0,4#49
r $17a082b0#f5
w $X2aaab1d0,4:\xfao;\x00#12
r $OK#9a
w $QPassSignals:#f3
r $OK#9a
w $vCont;c:p33e.33e#16\x03  <=== here
r $T05swbreak:;1b:f8f6fe7f;20:d0b1aa2a;thread:p33e.33e;core:0;#89

FAOD, this is a trunk checkout with the patch described above applied 
and nothing else.  And, the exact sequence of commands I'm using to try 
to reproduce this is

<target>-gdb a.out
target remote ...
break main
c
^C

-Sandra