From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22035 invoked by alias); 23 Oct 2002 21:13:41 -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 22025 invoked from network); 23 Oct 2002 21:13:39 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (62.163.169.250) by sources.redhat.com with SMTP; 23 Oct 2002 21:13:39 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.5/8.12.5) with ESMTP id g9NLDNsm001178; Wed, 23 Oct 2002 23:13:23 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6/8.12.6) with ESMTP id g9NLDNnJ000799; Wed, 23 Oct 2002 23:13:23 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6/8.12.6/Submit) id g9NLDMxA000796; Wed, 23 Oct 2002 23:13:22 +0200 (CEST) Date: Wed, 23 Oct 2002 14:13:00 -0000 Message-Id: <200210232113.g9NLDMxA000796@elgar.kettenis.dyndns.org> From: Mark Kettenis To: drow@mvista.com CC: gdb-patches@sources.redhat.com, msnyder@redhat.com In-reply-to: <20021023042615.GA6358@nevyn.them.org> (message from Daniel Jacobowitz on Wed, 23 Oct 2002 00:26:15 -0400) Subject: Re: RFA: lin-lwp bug with software-single-step or schedlock References: <20021023042615.GA6358@nevyn.them.org> X-SW-Source: 2002-10/txt/msg00475.txt.bz2 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. 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. Mark