On 03/19/2015 04:20 AM, Michael Neuling wrote:

On Thu, 2015-03-19 at 09:45 +1100, Michael Neuling wrote:

quoted

On Wed, 2015-03-18 at 13:53 +0100, Ulrich Weigand wrote:

quoted

Michael Neuling [off-list ref] wrote on 23.02.2015 05:51:50:

quoted

Sorry for the slow response.

Same here :-(

I'm going to break the cycle and respond in a few hours :-)

quoted

quoted

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>

quoted

quoted

quoted

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.

quoted

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.

Anshuman,

With that in mind, do we have a way to set the top 32bits of the MSR
(which contain the TM bits) when ptracing 32 bit processes?  I can't
find anything like that in this patch set.

No, we dont have that yet. When ptracing in 32-bit mode the MSR value
which can be viewed or set from the user space through PTRACE_GETREGS
PTRACE_SETREGS call is it's lower 32 bits only. Either we can club
the upper 32 bits of MSR as part of one of the ELF core notes we are
adding in the patch series or we can create one more separate ELF core
note for that purpose. Let me know your opinion on this.