From owner-freebsd-stable  Thu Jan  3 23:45:17 2002
Delivered-To: freebsd-stable@freebsd.org
Received: from web14003.mail.yahoo.com (web14003.mail.yahoo.com [216.136.175.94])
	by hub.freebsd.org (Postfix) with SMTP id D735A37B41E
	for <freebsd-stable@freebsd.org>; Thu,  3 Jan 2002 23:45:07 -0800 (PST)
Message-ID: <20020104074507.48785.qmail@web14003.mail.yahoo.com>
Received: from [216.103.213.142] by web14003.mail.yahoo.com via HTTP; Thu, 03 Jan 2002 23:45:07 PST
Date: Thu, 3 Jan 2002 23:45:07 -0800 (PST)
From: k Macy <kip_macy@yahoo.com>
Subject: ptrace bug was Re: gnu/33262: gdb does not handle pending signals correctly when single stepping
To: Donald Gillies <dgillies@graviton.com>,
	freebsd-gnats-submit@FreeBSD.org, freebsd-stable@freebsd.org,
	freebsd-hackers@freebsd.org
Cc: kip_macy@yahoo.com
In-Reply-To: <1171E12B84A02B4584B3BD41F8D7E29E3644D4@NTEXCH.graviton.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-freebsd-stable@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-stable.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-stable>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-stable>
X-Loop: FreeBSD.ORG

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-stable" in the body of the message