On Mon, Dec 14, 2009 at 11:26:26AM -0800, Roland McGrath wrote: <snipped> > I understand the reason for using stepping. (I have advised in the past > that I thought this magical implicit step logic was too hairy to roll in > under the covers and that a low-level facility expressing the different > hardware semantics to a kernel API would be OK. I do agree with the > motivation of cross-arch uniformity of the semantics. I don't object to > making it magically right--I just expressed general skepticism/fear about > getting that right so that I didn't want to try writing that magic. Now > I'm just responding about the particular details I've noticed about that > can of worms. It's certainly great if you can resolve all that. But I'll > note that I am still by no means confident that the details I have raised > cover all the worms in that can.) > > What remains less than clear is how preemption relates. For any per-thread > hw_breakpoint, there is no high-level reason to care one way or the other. > The thread, its HW breakpoints, its register state including state of > stepping, are all part of per-thread state and no reason to do any less (or > more) preemption than normally happens. >
I get that reasoning now...I'd been unduly worried about pre-emption and hence the introduction of pre-emption disabled state. But of course, in the existing design, the per-cpu variables would be affected because if pre-emption was to occur. I'll see how that can be factored in, while retaining the abstraction provided by the interfaces. > > Disabling pre-emption is necessary to ensure that hw-breakpoints are > > enabled immediately after the causative instruction has finished > > execution (the control flow may go astray if pre-emption occurs between > > i1 and i2). > > I don't understand what "go astray" means here. The only thing I can think > of is the effect on any per-cpu variables you are using in hw_breakpoint > implementation. > As stated above, I was worried about a pre-emption happening between a return from breakpoint exception handler and the execution of the causative instruction....but as I learn, it seems fine now. It is just that the kernel code needs to be tweaked keeping this in mind. Thanks, K.Prasad _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
