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. 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. This might not happen until unother profiling interrupt clobbers the saved pc, not to mention the saved tick count (it could just increment the tick count so that ticks are assigned to the last saved pc instead of lost; currently, the tick count mostly just tracks KEF_OWEUPC so it need not be saved). This was broken by SMPng (hardclock() is not really a fast interrupt handler but is abused as one). However, normal applications probably make enough syscalls to get the right counter updated, provided we use the counter for the pc at fast interrupt time and not the counter for the pc later. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
