This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
Re: testsuite/2033: sigbpt.exp fails on Solaris10 and Solaris9 (possibly others)
- From: "Steve Williams" <steve dot williams at utstar dot com>
- To: unasigned at sourceware dot org
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 4 Jan 2006 00:18:02 -0000
- Subject: Re: testsuite/2033: sigbpt.exp fails on Solaris10 and Solaris9 (possibly others)
- Reply-to: "Steve Williams" <steve dot williams at utstar dot com>
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--