On Nov 29, 2007 2:55 PM, Paul Mundt <[EMAIL PROTECTED]> wrote: > The only thing to be careful of is the ordering semantics for the T-bit > state, which is what I tried to convey in the code snippet. > > > > You can see an example in arch/sh/kernel/entry-common.S: > > > > > > syscall_exit_work: > > > ! r0: current_thread_info->flags > > > ! r8: current_thread_info > > > tst #_TIF_SYSCALL_TRACE | _TIF_SINGLESTEP | > > > _TIF_SYSCALL_AUDIT, r0 > > > bt/s work_pending > > > tst #_TIF_NEED_RESCHED, r0 > > > > > > .... > > > work_pending: > > > ! r0: current_thread_info->flags > > > ! r8: current_thread_info > > > ! t: result of "tst #_TIF_NEED_RESCHED, r0" > > > bf/s work_resched > > > tst #(_TIF_SIGPENDING | _TIF_RESTORE_SIGMASK), r0 > > > > So while bt/s is conditional on the first flag test, the T-state is > relative to the second test by the time the branch happens.
Exactly. > The T-state check for bt/bf happens _prior_ to execution of the delay > slot instruction, while any delay-slot resident T-bit modifier is > executed by the time we enter the branch. I don't know if your code > handles that or not, but figured it's probably good to make that > explicit. T-bit modifiers are always a bit hairy.. Yeah, the T flag is indeed a bit hairy. The patch should handle the T bit exactly as you describe it. As part of the bt/bf instruction the T flag is evaluated and if true the the DELAY_SLOT_TRUE bit is set. This bit is later used to decide if we should jump or not after the delay slot instruction. Thank you, / magnus
