From owner-freebsd-bugs  Thu Jan  3 23:50: 9 2002
Delivered-To: freebsd-bugs@hub.freebsd.org
Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id 5C52337B41C
	for <freebsd-bugs@hub.freebsd.org>; Thu,  3 Jan 2002 23:50:02 -0800 (PST)
Received: (from gnats@localhost)
	by freefall.freebsd.org (8.11.6/8.11.6) id g047o2O71774;
	Thu, 3 Jan 2002 23:50:02 -0800 (PST)
	(envelope-from gnats)
Date: Thu, 3 Jan 2002 23:50:02 -0800 (PST)
Message-Id: <200201040750.g047o2O71774@freefall.freebsd.org>
To: freebsd-bugs@FreeBSD.org
Cc: 
From: k Macy <kip_macy@yahoo.com>
Subject: ptrace bug was Re: gnu/33262: gdb does not handle pending signals correctly when single stepping
Reply-To: k Macy <kip_macy@yahoo.com>
Sender: owner-freebsd-bugs@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-bugs.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-bugs>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-bugs>
X-Loop: FreeBSD.org

The following reply was made to PR gnu/33262; it has been noted by GNATS.

From: k Macy <kip_macy@yahoo.com>
To: Donald Gillies <dgillies@graviton.com>,
	freebsd-gnats-submit@FreeBSD.org, freebsd-stable@freebsd.org,
	freebsd-hackers@freebsd.org
Cc: kip_macy@yahoo.com
Subject: ptrace bug was Re: gnu/33262: gdb does not handle pending signals correctly when single stepping
Date: Thu, 3 Jan 2002 23:45:07 -0800 (PST)

 Not to mention that SIGVTALRM is already used by 
 the thread library (although I would hope that
 _thread_sys_sigaction is smart enough to handle
 that case). I've stepped through the GDB
 code on both 4.18 and 5.1. On 5.1 I found the
 following in i386fbsd-nat.c:
 
 void
 child_resume (ptid_t ptid, int step, enum
 target_signal signal)
 {
   pid_t pid = ptid_get_pid (ptid);
   int request = PT_STEP;
 
   if (pid == -1)
     /* Resume all threads.  This only gets used in the
 non-threaded
        case, where "resume all threads" and "resume
 inferior_ptid" are
        the same.  */
     pid = ptid_get_pid (inferior_ptid);
 
   if (!step)
     {
       unsigned int eflags;
 
       /* Workaround for a bug in FreeBSD.  Make sure
 that the trace
          flag is off when doing a continue.  There is
 a code path
          through the kernel which leaves the flag set
 when it should
          have been cleared.  If a process has a signal
 pending (such
          as SIGALRM) and we do a PT_STEP, the process
 never really has
          a chance to run because the kernel needs to
 notify the
          debugger that a signal is being sent. 
 Therefore, the process
          never goes through the kernel's trap()
 function which would
          normally clear it.  */
 
       eflags = read_register (PS_REGNUM);
       if (eflags & 0x0100)
         write_register (PS_REGNUM, eflags & ~0x0100);
 
       request = PT_CONTINUE;
     }
 
 It is pretty clear that: 
 a) this does not deal with the case of step or next
 b) this does not work in the case of continue often
    times because step will be set to 1
 and hence, this code does _not_ work around the bug.
 
 This appears to be less of a GDB bug and more of a
 kernel bug in ptrace.
 
                     -Kip
 
 --- Donald Gillies <dgillies@graviton.com> wrote:
 > I think this bug may be associated only with the
 > SIGALRM signal.  When I
 > convert my code to use SIGVTALRM, the problem goes
 > away.  Unfortunately,
 > SIGVTALRM does not do exactly 
 > what I am looking for !!
 >  
 > # gdb 5.10
 > # $FreeBSD: src/COPYRIGHT,v 1.4 1999/09/05 21:33:47
 > obrien Exp $
 > #       @(#)COPYRIGHT   8.2 (Berkeley) 3/21/94
 >  
 > 
 >  
 
 
 __________________________________________________
 Do You Yahoo!?
 Send your FREE holiday greetings online!
 http://greetings.yahoo.com

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message