Re: [V6,1/9] elf: Add new powerpc specifc core note sections

[Ulrich Weigand <Ulrich.Weigand@de.ibm.com>]

Michael Neuling <mikey@neuling.org> wrote on 22.01.2015 00:39:57:
> On Thu, 2015-01-01 at 13:38 +0530, Anshuman Khandual wrote:
> > On 12/20/2014 12:58 AM, Edjunior Barbosa Machado wrote:
> > > The patchset seems to change the "original" ptrace requests (i.e.
> > > PTRACE_GETREGS/GETFPREGS/GETVRREGS...) to return the
> > > "transactional" state, and adds new register sets to return
> > > the "checkpointed" state.  Considering that whenever you get
> > > a debugger interception inside a transactional block, the
> > > transaction will abort, we're wondering if it wouldn't make
> > > more sense to display the 'checkpointed' state as the normal
> > > registers since this is where the execution will continue from.
> >
> > Debugger interception (trace interrupt) in between any transaction
> > block will abort it ? I doubt that.
>
> The trace interrupt will not abort the transaction explicitly...
>
> > The tracee process will just stop, it's context gets saved in the
> > kernel so that it can again start executing from the exact same
> > point onward when it resumes.
>
> ... unfortunately, this save *will* doom the transaction.  To save, a
> treclaim instruction is run which will always explicitly doom the
> transaction.
>
> > If this happens when inside any transaction block, the transaction's
running
> > context and check pointed context will get saved. The execution
> > will again start from the running context values instead of check
> > pointed when the process resumes. Check pointed values will be loaded
> > back into the context when the transaction finishes.
>
> Although since the transaction has been explicitly doomed, the hardware
> will *always* abort at this point and start execution from the
> checkpointed values.
>
> > 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).

>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:

- the "normal" ptrace register set commands should access the
  *checkpointed* registers (allowing both read and write access)

  -- 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

- a new ptrace register set should allow access (read-only) to the
  *running* register values

  -- GDB can use this to display the position inside the transaction
  at the point it aborted, using new transaction-specific commands


Bye,
Ulrich