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

[Michael Neuling]

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