From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5070 invoked by alias); 11 Sep 2002 00:19:56 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 5063 invoked from network); 11 Sep 2002 00:19:56 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 11 Sep 2002 00:19:56 -0000 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id RAA09740; Tue, 10 Sep 2002 17:09:17 -0700 (PDT) Message-ID: <3D7E8C2B.55D6D0BA@redhat.com> Date: Tue, 10 Sep 2002 17:19:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: gdb-patches@sources.redhat.com, tonny.madsen@nettest.com Subject: Re: Patch that provides true single step for multi-threaded /proc based processes (Tru64 5.1A) References: <3D6ADE55.9FD29B65@redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-09/txt/msg00173.txt.bz2 Tonny, Did you want to follow up on this? If you give me a changelog entry, I'll check in this change. Thanks, Michael Snyder Michael Snyder wrote: > > Howdy everybody, > > Hello Tony. > > First off -- could you please post in plain text next time? > As you may be able to see, some of us use news readers that > don't handle mark-up languages. > > Secondly, please excuse the long delay in reply. Your patch looks > OK to me. We will need a change-log entry, and then it can go in. > > Thanks, > > Michael Snyder > 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;