On Thu, 2015-01-01 at 13:38 +0530, Anshuman Khandual wrote:

On 12/20/2014 12:58 AM, Edjunior Barbosa Machado wrote:

quoted

On 12/08/2014 08:08 AM, Anshuman Khandual wrote:

quoted

On 12/03/2014 12:18 PM, Anshuman Khandual wrote:

quoted

On 12/03/2014 10:52 AM, Michael Ellerman wrote:

quoted

On Tue, 2014-02-12 at 07:56:45 UTC, Anshuman Khandual wrote:

quoted

This patch adds four new ELF core note sections for powerpc
transactional memory and one new ELF core note section for
powerpc general miscellaneous debug registers. These addition
of new ELF core note sections extends the existing ELF ABI
without affecting it in any manner.

Acked-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Anshuman Khandual <redacted>
---
 include/uapi/linux/elf.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h
index ea9bf25..2260fc0 100644
--- a/include/uapi/linux/elf.h
+++ b/include/uapi/linux/elf.h

@@ -379,6 +379,11 @@ typedef struct elf64_shdr {
 #define NT_PPC_VMX	0x100		/* PowerPC Altivec/VMX registers */
 #define NT_PPC_SPE	0x101		/* PowerPC SPE/EVR registers */
 #define NT_PPC_VSX	0x102		/* PowerPC VSX registers */
+#define NT_PPC_TM_SPR	0x103		/* PowerPC TM special registers */
+#define NT_PPC_TM_CGPR	0x104		/* PowerpC TM checkpointed GPR */
+#define NT_PPC_TM_CFPR	0x105		/* PowerPC TM checkpointed FPR */
+#define NT_PPC_TM_CVMX	0x106		/* PowerPC TM checkpointed VMX */
+#define NT_PPC_MISC	0x107		/* PowerPC miscellaneous registers */

This is a really terrible name, "MISC".

Having said that, I guess it's accurate. We have a whole bunch of re=

gs that

quoted

quoted

quoted

quoted

have accrued over recent years that aren't accessible via ptrace.

It seems to me if we're adding a misc regset we should be adding eve=

rything we

quoted

quoted

quoted

quoted

might want to it that is currenty architected.

But I believe they also need to be part of the thread_struct structur=

e to be

quoted

quoted

quoted

accessible from ptrace.

Currently we dont context save/restore the PMC count registers (PMC1-P=

MC6)

quoted

quoted

during the process context switch. So the values of PMC1..PMC6 are not
thread specific in the structure. To be able to access them in ptrace
when the tracee has stopped, we need to context save these counters
in the thread struct. Shall we do that ? Then we can add them to the
MISC regset bucket irrespective of whats the value we get in there whe=

n

quoted

quoted

we probe through ptrace.

The same goes for MMCRA, CFAR registers as well.

quoted

=20

quoted

But currently you only include the PPR, TAR & DSCR.

Yeah, thats what we started with.

quoted

Looking at Power ISA v2.07, I see the following that could be includ=

ed:

quoted

quoted

quoted

quoted

  MMCR2
  MMCRA
  PMC1
  PMC2
  PMC3
  PMC4
  PMC5
  PMC6
  MMCR0
  EBBHR
  EBBRR
  BESCR
  SIAR
  SDAR
  CFAR?

MMCRA, PMC[1..6], EBBHR, BESCR, EBBRR, CFAR are not part of the threa=

d struct.

quoted

quoted

Sorry. EBBRR, EBBHR, BESCR registers are part of the thread struct.

quoted

quoted

Those are all new in 2.07 except for CFAR.

There might be more I missed, that was just a quick scan.

Some are only accessible when EBB is in use, maybe those could be a =

separate

quoted

quoted

quoted

quoted

regset.

Yeah we can have one more regset for EBB specific registers.

Should the new EBB specific regset include only EBBRR, EBBHR, BESCR re=

gisters

quoted

quoted

or should it also include SIAR, SDAR, SIER, MMCR0, MMCR2 registers as =

well. I

quoted

quoted

was thinking about putting these five registers into the MISC bucket i=

nstead.

quoted

quoted

But from the perf code, it looks like these five registers are also re=

lated to

quoted

quoted

the EBB context as well.

Some clarity on these points would really help.

=20
Hi,
=20
from the provided testcase using ptrace interface, reviewing with the h=

elp

quoted

of Ulrich, it looks OK from GDB perspective, with the exception of a fe=

w

quoted

concerns:
=20
The patchset seems to change the "original" ptrace requests (i.e.
PTRACE_GETREGS/GETFPREGS/GETVRREGS...) to return the "transactional" st=

ate, and

quoted

adds new register sets to return the "checkpointed" state. Considering =

that

quoted

whenever you get a debugger interception inside a transactional block, =

the

quoted

transaction will abort, we're wondering if it wouldn't make more sense =

to=20

quoted

display the 'checkpointed' state as the normal registers since this is =

where the

quoted

execution will continue from.

=20
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 onw=

ard when it

resumes.=20

... 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 runn=

ing

context and check pointed context will get saved. The execution will agai=

n start from

the running context values instead of check pointed when the process resu=

mes. 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 in=

dependently.

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. =20

Mikey

quoted

=20
Also, we've noticed that the 'misc' regset contains registers from diff=

erent ISA

quoted

versions (dscr and ppr appear in ISA 2.05, tar is from 2.07). I'm not s=

ure if

quoted

there is a way to detect presence/validity of such registers, but perha=

ps it

quoted

might be a good idea to separate registers from different ISAs in diffe=

rent

quoted

regsets.

=20
Thats right, will use feature CPU_FTR_ARCH_207S (which checks whether we =

are v2.07

compliant) to detect whether TAR register is available or not.=20
=20

quoted

=20
Regarding the inclusion of other registers along with the EBB-related o=

nes, I'm

quoted

sorry but I'm not familiar with them.

=20
Michael Ellerman mentioned that we can look into them separately sometime=

 later

not in this patch series.
=20
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev