testsuite/2033: sigbpt.exp fails on Solaris10 and Solaris9 (possibly others)

Steve Williams steve.williams@utstar.com
Wed Jan 4 00:18:00 GMT 2006


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

From: "Steve Williams" <steve.williams@utstar.com>
To: <gdb-gnats@sources.redhat.com>
Cc:  
Subject: Re: testsuite/2033: sigbpt.exp fails on Solaris10 and Solaris9 (possibly others)
Date: Tue, 3 Jan 2006 16:12:49 -0800

 This is a multi-part message in MIME format.
 
 ------=_NextPart_000_000F_01C61080.98313DA0
 Content-Type: text/plain;
 	charset="us-ascii"
 Content-Transfer-Encoding: 7bit
 
 
 
 Patch to allow signals to be delivered while using the procfs single step.
 
 The patch works by changing the process state from PR_FAULTED to the
 PR_REQUESTED state, before performing the single step.
 
 
 ------=_NextPart_000_000F_01C61080.98313DA0
 Content-Type: application/octet-stream;
 	name="gdb64-procfs-stepping.patch"
 Content-Transfer-Encoding: quoted-printable
 Content-Disposition: attachment;
 	filename="gdb64-procfs-stepping.patch"
 
 --- gdb-6.4/gdb/procfs.c	2005-02-15 07:49:14.000000000 -0800=0A=
 +++ gdb-6.4p/gdb/procfs.c	2005-12-04 20:01:55.992047000 -0800=0A=
 @@ -351,6 +351,7 @@=0A=
    /* process state */=0A=
    int was_stopped;=0A=
    int ignore_next_sigstop;=0A=
 +  int stepping;=0A=
  =0A=
    /* The following four fd fields may be identical, or may contain=0A=
       several different fd's, depending on the version of /proc=0A=
 @@ -1736,6 +1737,7 @@=0A=
  {=0A=
    int win;=0A=
    int runflags;=0A=
 +  int i;=0A=
  =0A=
    /*=0A=
     * We will probably have to apply this operation to individual =
 threads,=0A=
 @@ -1750,7 +1752,45 @@=0A=
  =0A=
    runflags    =3D PRCFAULT;	/* always clear current fault  */=0A=
    if (step)=0A=
 -    runflags |=3D PRSTEP;=0A=
 +    {=0A=
 +      runflags |=3D PRSTEP;=0A=
 +	 =0A=
 +      if(!pi->stepping)=0A=
 +	{=0A=
 +	  /* This is to address a problem on Solaris, I am not sure=0A=
 +	  if it is the same on other /proc based OS's.=0A=
 +=0A=
 +	  If the process has pending signals, they will not be=0A=
 +	  delivered to the representative lwp if we step while in=0A=
 +	  the PR_FAULTED state. The fix implemented here first=0A=
 +	  transistions the inferior to a PR_REQUESTED state=0A=
 +	  using a flag of PCSTOP.=0A=
 +=0A=
 +	  In procfs_wait, the stepping flag is detected in=0A=
 +	  state PR_REQUESTED and a subsequent call to=0A=
 +	  proc_run_process is made which will now perform=0A=
 +	  a PCRUN with option PRSTEP. The signal is now=0A=
 +	  delivered while stepping in this state.=0A=
 +	 =0A=
 +	  The proc man page states that a PCRUN with flag=0A=
 +	  PRSTOP will not execute any user code.  */=0A=
 +=0A=
 +	  for(i=3D0; i<NSIG; i++)=0A=
 +	    {=0A=
 +	      /* Can't use proc_get_pending_signals, as this will look=0A=
 +		 in the representative lwp status and the pending signals=0A=
 +		 for the process are in the process status. */=0A=
 +	      if(sigismember(&pi->prstatus.pr_sigpend, i) =3D=3D 1)=0A=
 +		{=0A=
 +		  runflags &=3D ~(PRSTEP);=0A=
 +		  runflags |=3D PRSTOP;=0A=
 +		  pi->stepping =3D 1;=0A=
 +		  break;=0A=
 +		}=0A=
 +	    }=0A=
 +	}=0A=
 +    }=0A=
 +=0A=
    if (signo =3D=3D 0)=0A=
      runflags |=3D PRCSIG;=0A=
    else if (signo !=3D -1)		/* -1 means do nothing W.R.T. signals */=0A=
 @@ -2037,6 +2077,9 @@=0A=
        return NULL;=0A=
  =0A=
  #ifdef NEW_PROC_API=0A=
 +  /* Is this right? certainly under solaris, pending signals=0A=
 +     for the process are in the process status not the lwp=0A=
 +     status, maybe the fields need to be OR'd */=0A=
    ret =3D &pi->prstatus.pr_lwp.pr_lwppend;=0A=
  #else=0A=
    ret =3D &pi->prstatus.pr_sigpend;=0A=
 @@ -4150,6 +4193,12 @@=0A=
  		wstat =3D (SIGSTOP << 8) | 0177;=0A=
  		break;=0A=
  #else=0A=
 +		if(pi->stepping)=0A=
 +		  {=0A=
 +		    proc_run_process (pi, 1, -1);=0A=
 +		    pi->stepping =3D 0;=0A=
 +		    goto wait_again;=0A=
 +		  }=0A=
  		if (retry < 5)=0A=
  		  {=0A=
  		    printf_filtered (_("Retry #%d:\n"), retry);=0A=
 
 ------=_NextPart_000_000F_01C61080.98313DA0--
 



More information about the Gdb-prs mailing list