From: Frank Rowand <frank_rowand@mvista.com>
To: John Marvin <jsm@udlkern.fc.hp.com>
Cc: parisc-linux@puffin.external.hp.com
Subject: Re: Single-stepping
Date: Thu, 16 Nov 2000 11:00:48 -0800 [thread overview]
Message-ID: <3A142EE0.5A7E5039@mvista.com> (raw)
In-Reply-To: 200011161244.FAA03502@udlkern.fc.hp.com
John Marvin wrote:
>
> Richard,
>
> >
> > Sorry, I worded that very badly. The code that moves the childs
> > IAOQ on is in the kernel, invoked as a result of the controlling
> > process calling ptrace(PTRACE_SINGLESTEP...) when the childs N
> > bit is set.
> >
>
> Great.
>
> > > Does this code properly handle branches in the delay slot of another
> > > branch? (you need to make sure you are not advancing the queues by just
> > > adding 4 to each element). One concern I have about this method is that
> >
> > Current code does
> >
> > /* Nullified, just crank over the queue. */
> > task_regs(child)->iaoq[0] = task_regs(child)->iaoq[1];
> > task_regs(child)->iasq[0] = task_regs(child)->iasq[1];
> > task_regs(child)->iaoq[1] = task_regs(child)->iaoq[0] + 4;
> >
> > Does that look right to you?
> >
>
> Yes, that is the correct way to do it (I'll assume the duplicated line
> is just a cut/paste error).
If iaoq[0] contains a branch, iaoq[1] is in the delay slot. The instruction
executed after iaoq[1] would then typically _not_ be iaoq[0] + 4 (the next
instruction would be the target of the branch at iaoq[0]).
> Sounds ok with me. And as long as there are no corner cases, it probably
> is the best solution, assuming we don't find another application for
> the recovery counter.
The recovery counter is very useful for performance measurement tools to
understand the cycles per instruction of a code path. (Using the recovery
counter for the debugger doesn't preclude using it for performance tools -
you just can't easily use it for both purposes at the same instant in time.)
> John
-Frank
--
Frank Rowand <frank_rowand@mvista.com>
MontaVista Software, Inc
next prev parent reply other threads:[~2000-11-16 19:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-16 12:44 Single-stepping John Marvin
2000-11-16 13:20 ` Single-stepping Richard Hirst
2000-11-16 19:00 ` Frank Rowand [this message]
2000-11-16 20:28 ` Single-stepping Richard Hirst
-- strict thread matches above, loose matches on Subject: below --
2000-11-20 5:43 Single-stepping John Marvin
2000-11-20 6:53 ` Single-stepping Alan Modra
2000-11-20 7:24 ` Single-stepping Stan Sieler
2000-11-20 9:05 ` Single-stepping Alan Modra
2000-11-20 18:47 ` Single-stepping Stan Sieler
2000-11-16 9:01 Single-stepping John Marvin
2000-11-16 12:00 ` Single-stepping Richard Hirst
2000-11-20 3:03 ` Single-stepping Alan Modra
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=3A142EE0.5A7E5039@mvista.com \
--to=frank_rowand@mvista.com \
--cc=frowand@mvista.com \
--cc=jsm@udlkern.fc.hp.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.