X-Mozilla-Status2: 00000000
Return-Path: <gdb-patches-owner@sources.redhat.com>
Delivered-To: ac131313@localhost.redhat.com
Received: from localhost (localhost [127.0.0.1])
	by localhost.redhat.com (Postfix) with ESMTP id 320633F12
	for <ac131313@localhost>; Wed, 26 Jun 2002 10:09:16 -0400 (EDT)
Received: from pop.sfbay.redhat.com
	by localhost with IMAP (fetchmail-5.9.11)
	for ac131313@localhost (single-drop); Wed, 26 Jun 2002 10:09:16 -0400 (EDT)
Received: from ges.redhat.com (cygnus-mx.sfbay.redhat.com [172.16.27.16])
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id DAA00637
	for <ac131313@runyon.sfbay.redhat.com>; Wed, 26 Jun 2002 03:09:36 -0700 (PDT)
Received: from sources.redhat.com (sources.redhat.com [209.249.29.67])
	by ges.redhat.com (8.11.6/8.11.6) with SMTP id g5QA85631915
	for <ac131313@cygnus.com>; Wed, 26 Jun 2002 03:08:05 -0700
Received: (qmail 13647 invoked by alias); 26 Jun 2002 10:09:29 -0000
Received: (qmail 13539 invoked from network); 26 Jun 2002 10:09:22 -0000
Received: from unknown (HELO c000.snv.cp.net) (209.228.32.71)
  by sources.redhat.com with SMTP; 26 Jun 2002 10:09:22 -0000
Received: (cpmta 22989 invoked from network); 26 Jun 2002 03:09:21 -0700
Received: from 80.63.166.106 (HELO madsen)
  by smtp.madsen.org (209.228.32.71) with SMTP; 26 Jun 2002 03:09:21 -0700
Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:gdb-patches-unsubscribe-ac131313=cygnus.com@sources.redhat.com>
List-Subscribe: <mailto:gdb-patches-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sources.redhat.com>
List-Help: <mailto:gdb-patches-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-patches-owner@sources.redhat.com
Delivered-To: mailing list gdb-patches@sources.redhat.com
X-Sent: 26 Jun 2002 10:09:21 GMT
From: "Tonny Madsen" <tonny@madsen.org>
To: <gdb-patches@sources.redhat.com>
Cc: <tonny.madsen@nettest.com>
Subject: Patch that provides true single step for multi-threaded /proc based processes (Tru64 5.1A)
Date: Wed, 26 Jun 2002 12:09:27 +0200
Message-ID: <000001c21cf9$8f15a4f0$0601a8c0@madsen>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0001_01C21D0A.529FFB90"

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C21D0A.529FFB90
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-length: 2200

Howdy everybody,
 
In the company I work for, we use Tru64 5.1A as the main development and
deployment platform. The rather poor support for this platform in gdb is
the cause of problems and we have devoted some resources to find a solve
the most serious og these (as seem by us).
 
Currently we use the mdebugread patch as weel to handle the special
sections in native Tru64 5.1A shared libraties.
 
One problem we have been bitten by a number of times was the lack of
true single step support for multi-threaded processes. As Tru64 5.1A is
/proc based, the functions in question are proc_run_process and
procfs_resume. In these functions single step support is only
implemented for the new /proc API. Please note that we use multi-CPU
machine so we are bitten by this often!
 
The following patch will add support for the ioctl PIOCTRUN (if defined)
in proc_run_process.
 
Please comment on this if you see anything wrong with it.
 
I don't know if the patch is general for all /proc based architectures,
but I currently expect so.
 
/tonny
 

--- gdb/procfs.c-orig 2002-02-14 02:57:36.000000000 +0100
+++ gdb/procfs.c 2002-06-26 10:16:34.000000000 +0200
@@ -1748,6 +1748,30 @@
win = (write (pi->ctl_fd, (char *) &cmd, sizeof (cmd)) == sizeof (cmd));
}
#else /* ioctl method */
+#ifdef PIOCTRUN
+ /*
+ * If we single step AND the PIOCTRUN ioctl is supported, then use
+ * this. This cures the problem when single stepping a
+ * multi-threaded program, when all the other threads (than the
+ * current single stepped one), may run free while single stepping.
+ *
+ * Note that only the PRSTEP flag is of interrest here (PRCFAULT and
+ * PRCSIG are not allowed).
+ */
+ if (step) {
+ /* Structure from proc(4) on Tru64 5.1A. */
+ struct {
+ long pr_count; /* number of threads to run */
+ tid_t pr_error_thread; /* set by kernel if error is detected */
+ struct prrun thread_1; /* prrun struct, containing thread ID of 1st
thread to run in thread_1.pr_tid */
+ } prrun;
+ memset(&prrun, 0, sizeof (prrun));
+ prrun.pr_count = 1;
+ prrun.thread_1.pr_flags = PRSTEP;
+ prrun.thread_1.pr_tid = pi->prstatus.pr_tid;
+ win = (ioctl (pi->ctl_fd, PIOCTRUN, &prrun) >= 0);
+ } else
+#endif
{
prrun_t prrun;


------=_NextPart_000_0001_01C21D0A.529FFB90
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-length: 6112

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2716.2200" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D895564408-26062002><FONT face=3DArial size=3D2>Howdy=20
everybody,</FONT></SPAN></DIV>
<DIV><SPAN class=3D895564408-26062002><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D895564408-26062002><FONT face=3DArial size=3D2>In the co=
mpany I=20
work for, we use Tru64 5.1A as the main development and deployment platform=
. The=20
rather poor support for this platform in gdb is&nbsp;the cause of problems =
and=20
we have devoted some resources to find a solve the most serious&nbsp;og=20
these&nbsp;(as seem by us).</FONT></SPAN></DIV>
<DIV><SPAN class=3D895564408-26062002><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D895564408-26062002><FONT face=3DArial size=3D2>Currently=
 we use the=20
mdebugread patch as weel to handle the special sections in native Tru64 5.1=
A=20
shared libraties.</FONT></SPAN></DIV>
<DIV><SPAN class=3D895564408-26062002><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D895564408-26062002><FONT face=3DArial size=3D2>One probl=
em we have=20
been bitten by a number of times was the lack of true single step support f=
or=20
multi-threaded processes. As Tru64 5.1A is /proc based, the functions&nbsp;=
in=20
question are proc_run_process and procfs_resume. In these functions single =
step=20
support is only implemented for the new /proc API. Please note that we use=
=20
multi-CPU machine so we are bitten by this often!</FONT></SPAN></DIV>
<DIV><SPAN class=3D895564408-26062002><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D895564408-26062002><FONT face=3DArial size=3D2>The follo=
wing patch=20
will add support for the ioctl PIOCTRUN (if defined) in=20
proc_run_process.</FONT></SPAN></DIV>
<DIV><SPAN class=3D895564408-26062002><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D895564408-26062002><FONT face=3DArial size=3D2>Please co=
mment on=20
this if you see anything wrong with it.</FONT></SPAN></DIV>
<DIV><SPAN class=3D895564408-26062002><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D895564408-26062002><FONT face=3DArial size=3D2>I don't k=
now if the=20
patch is general for all /proc based architectures, but I currently expect=
=20
so.</FONT></SPAN></DIV>
<DIV><SPAN class=3D895564408-26062002><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D895564408-26062002><FONT face=3DArial=20
size=3D2>/tonny</FONT></SPAN></DIV>
<DIV><SPAN class=3D895564408-26062002><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV><SPAN class=3D895564408-26062002>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV><FONT face=3D"Courier New" size=3D2>--- gdb/procfs.c-orig 2002-02-14=
=20
  02:57:36.000000000 +0100</FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>+++ gdb/procfs.c 2002-06-26=20
  10:16:34.000000000 +0200</FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>@@ -1748,6 +1748,30 @@</FONT></D=
IV>
  <DIV><FONT face=3D"Courier New" size=3D2>win =3D (write (pi-&gt;ctl_fd, (=
char *)=20
  &amp;cmd, sizeof (cmd)) =3D=3D sizeof (cmd));</FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>}</FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>#else /* ioctl method */</FONT><=
/DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>+#ifdef PIOCTRUN</FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>+ /*</FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>+ * If we single step AND the PI=
OCTRUN=20
  ioctl is supported, then use</FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>+ * this. This cures the problem=
 when=20
  single stepping a</FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>+ * multi-threaded program, when=
 all the=20
  other threads (than the</FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>+ * current single stepped one),=
 may run=20
  free while single stepping.</FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>+ *</FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>+ * Note that only the PRSTEP fl=
ag is of=20
  interrest here (PRCFAULT and</FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>+ * PRCSIG are not allowed).</FO=
NT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>+ */</FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>+ if (step) {</FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>+ /* Structure from proc(4) on T=
ru64=20
  5.1A. */</FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>+ struct {</FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>+ long pr_count; /* number of th=
reads to=20
  run */</FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>+ tid_t pr_error_thread; /* set =
by kernel=20
  if error is detected */</FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>+ struct prrun thread_1; /* prru=
n struct,=20
  containing thread ID of 1st thread to run in thread_1.pr_tid */</FONT></D=
IV>
  <DIV><FONT face=3D"Courier New" size=3D2>+ } prrun;</FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>+ memset(&amp;prrun, 0, sizeof=20
  (prrun));</FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>+ prrun.pr_count =3D 1;</FONT></=
DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>+ prrun.thread_1.pr_flags =3D=20
  PRSTEP;</FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>+ prrun.thread_1.pr_tid =3D=20
  pi-&gt;prstatus.pr_tid;</FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>+ win =3D (ioctl (pi-&gt;ctl_fd,=
 PIOCTRUN,=20
  &amp;prrun) &gt;=3D 0);</FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>+ } else</FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>+#endif</FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>{</FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>prrun_t=20
prrun;</FONT></DIV></BLOCKQUOTE><FONT size=3D2>
<P><FONT face=3DArial></FONT></P></FONT></SPAN></BODY></HTML>

------=_NextPart_000_0001_01C21D0A.529FFB90--


