This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: Patch that provides true single step for multi-threaded /proc based processes (Tru64 5.1A)
- From: Michael Snyder <msnyder at redhat dot com>
- To: gdb-patches at sources dot redhat dot com, tonny dot madsen at nettest dot com
- Date: Tue, 10 Sep 2002 17:19:55 -0700
- Subject: Re: Patch that provides true single step for multi-threaded /proc based processes (Tru64 5.1A)
- Organization: Red Hat, Inc.
- References: <3D6ADE55.9FD29B65@redhat.com>
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;