Apparently, On Mon, Feb 17, 2003 at 05:35:09PM +1100,
Bruce Evans said words to the effect of;
> On Sun, 16 Feb 2003, Julian Elischer wrote:
>
> > In addupc_intr, if the increment cannot be done immediatly, the addres
> > to increment the count for is stored and the increment is done later at
> > ast or userret() time...
>
> Note that "cannot be done immediatly" is "always except on sparc64's"
> under FreeBSD, since incrementing the counter immediately is only
> implemented on sparc64's.
>
> > is there any reason that the address of the PC needs to be stored?
> > why is the address from the frame at that time not useable?
> >
> > is it because the PC in the return frame may be hacked up for signals?
>
> That's was good a reason as any. I think the next return to user mode
> is to the signal handler's context (if there is a signal to be handled).
> It would be wrong to use the signal handler's pc. Also, ast() doesn't
> have access to the frame, and there is no macro like CLKF_PC() for
> general frames. This probably doesn't matter much, since signals are
> rare and the hitting on the signal handler's pc would be perfectly
> correct if the profiling interrupt occurred an instant later.
There are macros for accessing trapframes, like the ones for clockframe,
TRAPF_PC etc.
>
> Now there is a stronger reason: clock interrupt handling is "fast",
> so it normally returns to user mode without going near ast(), and the
> counter is not updated until the next non-fast interrupt or syscall.
In freebsd "fast" interrupts do handle asts, on i386 they return through
doreti (you may consider this a bug and have removed it in your version).
I see no reason not to just use the pc in the trapframe passed to ast,
even in the case of signals they won't be posted until after addupc_task
is called.
Jake
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
