From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32662 invoked by alias); 23 Oct 2002 21:44:10 -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 32650 invoked from network); 23 Oct 2002 21:44:09 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 23 Oct 2002 21:44:09 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id g9NLMiw21932 for ; Wed, 23 Oct 2002 17:22:44 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id g9NLi8l10483; Wed, 23 Oct 2002 17:44:08 -0400 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id g9NLi7D26412; Wed, 23 Oct 2002 14:44:07 -0700 Message-ID: <3DB71827.3195CECD@redhat.com> Date: Wed, 23 Oct 2002 14:44:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: Mark Kettenis CC: drow@mvista.com, gdb-patches@sources.redhat.com Subject: Re: RFA: lin-lwp bug with software-single-step or schedlock References: <20021023042615.GA6358@nevyn.them.org> <200210232113.g9NLDMxA000796@elgar.kettenis.dyndns.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-10/txt/msg00480.txt.bz2 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. Uh, you didn't. I did. You copied it from "lin-thread.c". And I wrote it because I found it empirically to be true at the time. > 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. The whole business is rather unplanned. The exact meaning and connotation of those variables is nowhere defined in writing. Mainly it's a matter of keeping consistent with what the code in gdb expects, which you sometimes have to guess, or learn by examining an older threaded architecture (eg. solaris). > 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. Sounds like something has changed upstream. > 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? That's what "prepare_to_proceed" is supposed to take care of. > 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. I'll pipe up and comment, as above, but I'll let you two guys work out the decision between you. Michael