> > > Inside transaction both running and check pointed values can be > > > probed independently. > > > > Yep, that's the idea, although setting the running values won't change > > anything since the the translation is already doomed and will abort once > > the cpu starts executing it. > > So this looks to me like the overall effect on debugging transactional > code should be the same on Power and z, even if some internal details > are different (on z, the exception will automatically abort the > transaction; on p, the exception itself will not abort, but *restarting* > user space execution will).
Yep > From a GDB perspective, it would therefore be preferable if the ptrace > interface were to behave in a similar fashion on p as on z: that is, > if an exception interrupting a transaction results in a ptrace intercept, > at this point: Agreed. > - the "normal" ptrace register set commands should access the > *checkpointed* registers (allowing both read and write access) OK, this is a change from what we've been proposing with Anshuman's patch set but I'm happy to change it to make it consistent with other architectures. It's relatively arbitrary which goes where, so I'm happy to change. > -- GDB will use this to display current position (already reflecting > the fact that the transaction will abort), and use it when changing > register values e.g. to effect an inferior function call "Current position" depends on your perspective. Is it the last executed instruction or the next executed instruction? If it's the last executed instruction, then it's the running values. If it's the next, then it's the check pointed. Anyway, I'm happy to make it the check pointed values for the sake of ptrace/gdb. > - a new ptrace register set should allow access (read-only) to the > *running* register values This is because changing them won't ever result in a side effect? > -- GDB can use this to display the position inside the transaction > at the point it aborted, using new transaction-specific commands Yep. Mikey PS in the subject s/specifc/specific/ -- 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/
