On Wed, 2015-03-18 at 13:53 +0100, Ulrich Weigand wrote: > Michael Neuling <mi...@neuling.org> wrote on 23.02.2015 05:51:50: > > > Sorry for the slow response. > > Same here :-(
I'm going to break the cycle and respond in a few hours :-) > > I think what you're proposing with running the inferior function in > > suspend mode may end up corrupting the stack in this way. You'd need to > > be really careful to make sure the inferior function is run on the stack > > pointer of the checkpointed registers. > > On the other hand, if code called a subroutine after the tbegin, if we > were using the checkpointed r1, this might corrupt the stack of the > transactional code. (This code will never actually *run* again since > the transaction is doomed, but we can still *inspect* it in GDB after > the inferior call has returned, so the stack should remain unchanged. > Well .. if the transaction is suspended, the code might in fact still > run, so it should remain unchanged either way.) > > I guess we could use the minimum of transactional and checkpointed r1 > in that case, to be safe either way. Sounds good. <snip> > > > Using the combination of (A)+(A') would be easiest to implement > > > in GDB without modifying a lot of common code, and would have the > > > advantage that the inferior function always executes in the same > > > state (suspended), while leaving information about the interrupted > > > transaction visible. > > > > > > Using the combination of (B)+(B') would be a bit more difficult > > > to implement (but certainly feasible), and would have the advantage > > > that the inferior function always executes in nontransactional state > > > (which is what it would most likely expect, anyway). However, the > > > disadvantage is that after the inferior call returns, GDB is unable > > > to fully restore the visible inferior state as it was before (since > > > we're now in nontransactional state, and there is probably no way > > > to force us back into transactional/suspended state ...). > > > > Yep. > > So right now I'd tend to prefer (A)+(A'), but the important thing is > that the kernel seems to provide all features required for GDB to > implement any of the above, so we can still make that decision later. > > > Getting back to the kernel interface, are you happy with what Anshuman > > has proposed in the current series? > > Given the discussion above, this seems fine to me now. Great, we'll push through with this in mind. Thanks! Mikey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
