On Wed, 10 Feb 2010 14:40:19 -0600 "Serge E. Hallyn" <serue@xxxxxxxxxx> wrote: > The current placement of get_signal_to_deliver() means that > try_to_freeze() in get_signal_to_deliver() will happen after > regs->psw.addr, regs->svcnr, and regs->gprs[2] may have been > mangled. Since the app may get checkpointed while frozen and > then restarted, this means we have to attempt a complicated > and subtle re-calculation of the initial conditions. > > If we just move the get_signal_to_deliver() above the > immediately preceding block, we enourmously simplify the > arch-specific checkpoint/restart code. > > A full ltp run seems to show no regressions do to this move, > though I'm not familiar enough with the entry_64.S code in > particular to be absolutely confident. > > Is this a bad idea? I think it is a bad idea. The comment of get_signal_to_deliver tells you that the debugger is invoked and may want to change the registers. If the get_signal_to_deliver calls is moved then the debugger sees the unmodified registers which is imho wrong. A comparison of the gdb testsuite with and without the patch will tell us more. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
