From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5304 invoked by alias); 23 Oct 2002 21:55:43 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 5291 invoked from network); 23 Oct 2002 21:55:43 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 23 Oct 2002 21:55:43 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 184UP8-0007W5-00; Wed, 23 Oct 2002 17:55:10 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 184TTq-0000Cs-00; Wed, 23 Oct 2002 17:55:58 -0400 Date: Wed, 23 Oct 2002 14:55:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: gdb-patches@sources.redhat.com, msnyder@redhat.com Subject: Re: RFA: lin-lwp bug with software-single-step or schedlock Message-ID: <20021023215558.GA32089@nevyn.them.org> Mail-Followup-To: Mark Kettenis , gdb-patches@sources.redhat.com, msnyder@redhat.com References: <20021023042615.GA6358@nevyn.them.org> <200210232113.g9NLDMxA000796@elgar.kettenis.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200210232113.g9NLDMxA000796@elgar.kettenis.dyndns.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-10/txt/msg00481.txt.bz2 On Wed, Oct 23, 2002 at 11:13:22PM +0200, Mark Kettenis wrote: > Date: Wed, 23 Oct 2002 00:26:15 -0400 > From: Daniel Jacobowitz > > This bug was noticed on MIPS, because MIPS GNU/Linux is > SOFTWARE_SINGLE_STEP_P. There's a comment in lin_lwp_resume: > > /* Apparently the interpretation of PID is dependent on STEP: If > STEP is non-zero, a specific PID means `step only this process > id'. But if STEP is zero, then PID means `continue *all* > processes, but give the signal only to this one'. */ > resume_all = (PIDGET (ptid) == -1) || !step; > > I'm fairly certain it's not without reason that I wrote this comment > as it is. I'm sure - I'd dearly like to know why, since I'm sure it'll bite us later :) > Now, I did some digging, and I believe this comment is completely > incorrect. Saying "signal SIGWINCH" causes PIDGET (ptid) == -1, > and it is assumed the signal will be delivered to inferior_ptid. > There's some other problem there - I think I've discovered that we > will neglect to single-step over a breakpoint if we are told to > continue with a signal, which is a bit dubious of a decision - but > by and large it works as expected. > > I don't see directly why, but I wouldn't be surprised by it. > > So if STEP is 0, we always resume all processes. STEP at this point _only_ > refers to whether we want a PTRACE_SINGLESTEP or equivalent; > SOFTWARE_SINGLE_STEP has already been handled. We can't make policy > decisions based on STEP any more. > > Indeed, there's something wrong here. > > I tried removing the || !step. It's pretty hard to tell, since there are > still a few non-deterministic failures on my test systems (which is what I > was actually hunting when I found this!) but I believe testsuite results are > improved on i386. > > There is one thing that might be affected. Suppose you have a signal > such as SIGUSR1 that stops the inferior but is also passed on to the > inferior. If a multi-threaded program gets this signal, GDB will > stop. If you now change the current thread to some other thread and > try to single-step. Will the signal be delivered to the origional > thread? > > If your patch doesn't affect this, I think your patch is OK to check > in. Otherwise we'll have to think about this a bit more. Well, let's see. There's some interesting behavior here. - stopped at GDB prompt, thread 8 current - say "signal SIGWINCH" - thread 8 gets the signal - stopped at GDB prompt, thread 8 current - say "thread 9" - say "signal SIGWINCH" - thread 9 gets the signal - stopped at GDB prompt, thread 8 current - say "thread 9" - say "set scheduler-locking on" - say "stepi" - thread 9 steps - thread 8 gets SIGWINCH (which is set to stop print pass in my session) - thread 8 is current thread at stop - say "continue" - thread 8 gets SIGWINCH - thread 8 gets SIGWINCH - thread 8 is current thread at stop - say "thread 9" - say "continue" - thread 9 gets SIGWINCH Oops. However, this behavior is 100% unchanged by my patch; that is, it didn't work before either. Using step instead of continue makes no difference either. Is my patch OK in this case? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer