This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]