This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch that provides true single step for multi-threaded /proc based processes (Tru64 5.1A)


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;


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]