From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12274 invoked by alias); 3 Aug 2010 13:17:43 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 12262 invoked by uid 22791); 3 Aug 2010 13:17:42 -0000 X-SWARE-Spam-Status: No, hits=-6.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Date: Tue, 03 Aug 2010 13:17:00 -0000 From: Oleg Nesterov To: Jan Kratochvil Cc: Roland McGrath , archer@sourceware.org, utrace-devel@redhat.com Subject: Re: Q: %Stop && gdb crash Message-ID: <20100803131436.GA2185@redhat.com> References: <20100716205147.GA26313@redhat.com> <20100721170400.GA30978@redhat.com> <20100721204203.D040C400B6@magilla.sf.frob.com> <20100723173134.GA29717@redhat.com> <20100726142759.GA17171@redhat.com> <20100728181702.GA26678@redhat.com> <20100802235358.GA9720@host1.dyn.jankratochvil.net> <20100803122434.GA32698@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100803122434.GA32698@redhat.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SW-Source: 2010-q3/txt/msg00080.txt.bz2 Forgot to mention, On 08/03, Oleg Nesterov wrote: > > So I assumed it is always safe to resend the notification unless gdb already > sent vStopped. Since it is not clear to me when it makes sense to resend it, > currently gdbstub does re-send every time /proc/ugdb reports the new event > (T00 in this case). I agree this is not optimal, but this looks correct to me. I'll change gdbstub to never resend the notification to avoid the problem. But probably gdb should be fixed anyway. And, now I recalled why I added resend into the initial code. This is because I hit another minor problem which I misinterpreted as if gdb can miss the notification. To avoid the unnecessary details, consider the oversimplified example, $ sleep 10000& [1] 2923 $ cat > SLEEP set target-async on set non-stop target extended-remote :2000 file /bin/sleep attach 2923 info registers detach ^D $ gdb This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-unknown-linux-gnu". For bug reporting instructions, please see: . (gdb) (gdb) (gdb) Remote debugging using :2000 (gdb) Reading symbols from /bin/sleep...(no debugging symbols found)...done. (gdb) Attached to process 2923 [New Thread 2923.2923] Target is executing. (gdb) Detached from remote process 2923. (gdb) quit And yes, gdb ignores %Stop and just detaches. But this is because of another issue (which looks like a minor gdb bug to me), note the "Target is executing." above. This is the reply to "info registers". Why? OK, yes, it is executing. Then send vCont:t ? "attach PID" means attach and stop it, no? And note, the same commands work as expected in CLI mode. I also tried to add "interrupt" before "info registers", this doesn't help although in this case gdb does send vStopped. Can't resist, I spent a lot of time trying to understand what is wrong. Because at first I played with the real gdbserver via CLI to ensure everything works as I expect, then I tried to achieve the same results with /proc/ugdb doing "$ gdb < BATCH_FILE" with the same commands. Oleg.