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 03:09:00 -0000 [thread overview]
Message-ID: <000001c21cf9$8f15a4f0$0601a8c0@madsen> (raw)
[-- Attachment #1: Type: text/plain, Size: 2200 bytes --]
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;
[-- Attachment #2: Type: text/html, Size: 5804 bytes --]
next reply other threads:[~2002-06-26 10:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-26 3:09 Tonny Madsen [this message]
2002-08-04 16:56 ` Andrew Cagney
2002-08-26 19:17 Michael Snyder
2002-09-10 17:19 ` Michael Snyder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='000001c21cf9$8f15a4f0$0601a8c0@madsen' \
--to=tonny@madsen.org \
--cc=gdb-patches@sources.redhat.com \
--cc=tonny.madsen@nettest.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox