From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26456 invoked by alias); 27 Aug 2002 02:05:10 -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 26448 invoked from network); 27 Aug 2002 02:05:10 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 27 Aug 2002 02:05:10 -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 SAA10438; Mon, 26 Aug 2002 18:58:15 -0700 (PDT) Message-ID: <3D6ADE55.9FD29B65@redhat.com> Date: Mon, 26 Aug 2002 19:17:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 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) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-08/txt/msg00887.txt.bz2 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;