From: Richard Hirst <rhirst@linuxcare.com>
To: parisc-linux@puffin.external.hp.com
Subject: [parisc-linux] Single-stepping
Date: Wed, 15 Nov 2000 18:48:08 +0000 [thread overview]
Message-ID: <20001115184808.P32715@linuxcare.com> (raw)
(Oops, CC-ed to the wrong list first time!)
Hi John,
I've been helping Alan Modra out with kernel changes to support
single stepping for gdb. Paul Bame suggested I bounced our ideas
off you in case you (or anyone else) had any comments. I havn't
actually committed my changes yet.
The basic approach is to use the recovery counter to generate
a trap every instruction. The scheme is complicated because a
suspended process may or may not return to user space via an RFI.
If it was suspended as a result of an interrupt then we can
simply set PSW bit R in the tasks saved registers and it will
get loaded by the RFI. On every task switch I set the
recovery counter to 0, just in case the new process is being
single-stepped.
If a process is suspended during a syscall, then there is no
RFI on the return path to userland, and we have to handle things
differently. I have changed the syscall return path such that
it loads the recovery counter with 3 before updating the PSW
with a value from the tasks saved registers. If that PSW has
the R bit set, then the count of 3 will generate a trap on the
first instruction following the branch back to user space.
Note that PSW wasn't previously restored on the syscall return
path.
To avoid further complications of interrupts during the three
instructions when the recovery counter is decrementing, whenever
we set the R bit, we also clear the I bit to disable interrupts.
Nullified instructions are handled by the controlling process
manually moving the childs IAOQ over the instruction without
actually setting it running, because the recovery counter isn't
decremented for nullified instructions.
I need to do some more testing before committing this, but would
welcome any comments on the basic approach taken, areas I have
mis-understood, or problems with it that might not yet have
occurred to me.
Thanks,
Richard
next reply other threads:[~2000-11-15 18:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-15 18:48 Richard Hirst [this message]
2000-11-15 19:49 ` [parisc-linux] Single-stepping John David Anglin
2000-11-15 20:30 ` law
2000-11-15 21:16 ` Frank Rowand
2000-11-15 21:47 ` Stan Sieler
2000-11-15 21:08 ` Stan Sieler
2000-11-16 12:09 ` Richard Hirst
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=20001115184808.P32715@linuxcare.com \
--to=rhirst@linuxcare.com \
--cc=parisc-linux@puffin.external.hp.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.