On Sun, Mar 06, 2005 at 01:22:25PM -0800, Roland McGrath wrote: > > I _think_ your test-case would work right if you just moved that code from > > the special-case in do_debug(), and moved it to the top of > > setup_sigcontext() instead. I've not tested it, though, and haven't really > > given it any "deep thought". Maybe somebody smarter can say "yeah, that's > > obviously the right thing to do" or "no, that won't work because.." > > Indeed, this is what my original changes for this did, before you started > cleaning things up to be nice to TF users other than PTRACE_SINGLESTEP. > > I note, btw, that the x86_64 code is still at that prior stage. So I think > it doesn't have this new wrinkle, but it also doesn't have the advantages > of the more recent i386 changes. Once we're sure about the i386 state, we > should update the x86_64 code to match. > > I'm not sure what kind of smart this makes me, but I'll say that your plan > would work and no, it's obviously not the right thing to do. ;-) I haven't > tested the following, not having tracked down the specific problem case you > folks are talking about. But I think this is the right solution. The > difference is that when we stop for some signal and report to the debugger, > the debugger looking at our registers will see TF clear instead of set, > before it decides whether to continue us with the signal or what to do. > With the change yo suggested, (I think) if the debugger decides to eat the > signal and resume, we would get a spurious single-step trap after executing > the next instruction, instead of resuming normally as requested.
Roland, the sigstep.exp test in the GDB testsuite will show this problem; if your patch monotonically improves GDB HEAD testsuite results and removes all the FAILs for sigstep.exp, then it's probably equivalent to the one I just posted for this testcase. I think mine is more correct; the problem doesn't occur because the debugger cancelled a signal, it occurs because a bogus TF bit was saved to the signal context. I like keeping solutions close to their problems. But that's just aesthetic. -- Daniel Jacobowitz CodeSourcery, LLC - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/