From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66259 invoked by alias); 20 Aug 2015 18:23:37 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 66246 invoked by uid 89); 20 Aug 2015 18:23:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 20 Aug 2015 18:23:34 +0000 Received: from svr-orw-fem-02x.mgc.mentorg.com ([147.34.96.206] helo=SVR-ORW-FEM-02.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1ZSUUs-0006j7-TN from Sandra_Loosemore@mentor.com ; Thu, 20 Aug 2015 11:23:30 -0700 Received: from [IPv6:::1] (147.34.91.1) by svr-orw-fem-02.mgc.mentorg.com (147.34.96.168) with Microsoft SMTP Server id 14.3.224.2; Thu, 20 Aug 2015 11:23:30 -0700 Message-ID: <55D61AA2.5000502@codesourcery.com> Date: Thu, 20 Aug 2015 18:23:00 -0000 From: Sandra Loosemore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Pedro Alves CC: Gary Benson , , Joel Brobecker , Doug Evans , Jan Kratochvil , =?windows-1252?Q?Andr=E9_P=F6nitz?= , Paul Koning Subject: Re: [PATCH] Prelimit number of bytes to read in "vFile:pread:" References: <55D3DB83.4050204@redhat.com> <1439980862-21305-1-git-send-email-gbenson@redhat.com> <20150819105054.GA22009@blade.nx> <55D4B190.6080700@codesourcery.com> <20150819172059.GA31845@blade.nx> <55D4F125.4080409@codesourcery.com> <55D5F799.9020700@redhat.com> <55D607B8.70103@redhat.com> In-Reply-To: <55D607B8.70103@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-08/txt/msg00557.txt.bz2 On 08/20/2015 11:00 AM, Pedro Alves wrote: > On 08/20/2015 04:51 PM, Pedro Alves wrote: > >> I don't see a quick, easy and good way around waiting for the whole file to read. >> Having GDB handle ctrl-c differently while it is handling internal events >> is already a source of trouble, and the fix always seemed to me to be to make ctrl-c >> work like what is happening here. Specifically, I mean that e.g., say that the >> user sets a conditional breakpoint that is evaluated on gdb's side, and then the >> target stops for that conditional breakpoint, gdb evaluates the expression, >> and then resumes the target again, on and on. If the user presses ctrl-c just >> while the conditional breakpoint's expression is being evaluated, and something along >> that code path called target_terminal_ours (thus pulling input/ctrl-c to the >> regular "Quit" SIGINT handler), gdb behaves differently (shows a "Quit" and the >> debug session ends up likely broken) from when the ctrl-c is pressed while the target >> is really running. I'd argue that the ctrl-c in both cases should be passed >> down all the way to the target the same way, and that any internal stop and >> breakpoint condition evaluation is magic that should be hidden. Just like >> what is happening here with file reading. >> >> Though having said that, it does look like even that isn't working properly, >> as I'd expect this: >> >> (top-gdb) c >> Continuing. >> (no debugging symbols found)...done. >> >> Breakpoint 1, main (argc=1, argv=0x7fffffffe3d8) at ../../../src/gdb/gdbserver/server.c:3635 >> 3635 ../../../src/gdb/gdbserver/server.c: No such file or directory. >> (gdb) >> >> to be slow (that is, the file reading isn't really interrupted), but then >> the target stops with SIGINT as soon as gdb resumes it again after reading >> the DSOs. But it is reaching main anyway, and there's no sign >> of "Program stopped with SIGINT"... >> >> Not sure where the bug is. It may be on the gdbserver side. > > OK, so gdbserver receives the \003, but since the target is stopped, > the normal packet processing loop discards the \003, as it doesn't > look like a start of a RSP packet frame (that is, it isn't a $). > > I'm thinking that maybe the best way to handle this may be to still > leave SIGINT forwarding to the target, so that in case gdb re-resumes > the target quick enough, the ctrl-c turns into a real SIGINT on the > target. But then if it takes long for gdb or gdbserver or the target > to react to the ctrl-c, then the user presses ctrl-c again, and gdb > shows the old: > > Interrupted while waiting for the program. > Give up (and stop debugging it)? (y or n) > > AFAICS, that query is never issued anywhere if the target > is async. And the remote target is always async nowadays. > > To make that query appear promptly, we'd hook it to the > QUIT macro. Something like this: > > (gdb) c > Continuing. > Reading symbols from target:/lib/x86_64-linux-gnu/libdl.so.2...(no debugging symbols found)...done. > Reading symbols from target:/lib/x86_64-linux-gnu/libc.so.6...(no debugging symbols found)...done. > ^CInterrupted while waiting for the program. > Give up (and stop debugging it)? (y or n) y > Quit > (gdb) > > Could you try the hacky patch below just to see if it makes a > difference to you? It seems that GDB still doesn't react > as soon as it could, but I'd guess that Gary's previous patch > to add a QUIT around vFile:pread's would fix that. Thanks! The combination of these two patches does make GDB respond quickly to the second ^C and abort the file transfer. However, both GDB and gdbserver seem to be left in a wonky state. On the GDB side, I'm seeing: (gdb) c Continuing. ^C^CInterrupted while waiting for the program. Give up (and stop debugging it)? (y or n) Interrupted while waiting for the program. y You can't do that when your target is `exec' No registers. (gdb) And, meanwhile on the target, gdbserver has done this: Process a.out created; pid = 856 Listening on port 6789 Remote debugging from host 134.86.188.141 readchar: Got EOF Remote side has terminated connection. GDBserver will reopen the connection. /scratch/sandra/nios2-linux-trunk/src/gdb-nios2r2/gdb/gdbserver/../common/cleanups.c:265: A problem internal to GDBserver has been detected. restore_my_cleanups has found a stale cleanup Listening on port 6789 I was thinking that the "right" behavior here would be for GDB to just try to continue without library symbol or debug information if the file transfer is interrupted, but a clean shutdown with fewer confusing messages would be OK, too. Especially if we've given users a hint that they need "set sysroot", the probable scenario is for the user to start over with a fresh GDB and add that command before "target remote". -Sandra