Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1204662 > unrolled thread

[PATCH v8 1/7] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature

Started byDavid Long <dave.long@linaro.org>
First post2015-08-11 03:00 +0200
Last post2015-08-18 11:40 +0200
Articles 4 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH v8 1/7] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature David Long <dave.long@linaro.org> - 2015-08-11 03:00 +0200
    Re: [PATCH v8 1/7] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature Will Deacon <will.deacon@arm.com> - 2015-08-11 19:40 +0200
      Re: [PATCH v8 1/7] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature David Long <dave.long@linaro.org> - 2015-08-13 06:00 +0200
        Re: [PATCH v8 1/7] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature Will Deacon <will.deacon@arm.com> - 2015-08-18 11:40 +0200

#1204662 — [PATCH v8 1/7] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature

FromDavid Long <dave.long@linaro.org>
Date2015-08-11 03:00 +0200
Subject[PATCH v8 1/7] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
Message-ID<pW655-66O-23@gated-at.bofh.it>
From: "David A. Long" <dave.long@linaro.org>

Add HAVE_REGS_AND_STACK_ACCESS_API feature for arm64.

Signed-off-by: David A. Long <dave.long@linaro.org>
---
 arch/arm64/Kconfig              |  1 +
 arch/arm64/include/asm/ptrace.h | 25 +++++++++++++
 arch/arm64/kernel/ptrace.c      | 77 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 103 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 318175f..ef5d726 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -70,6 +70,7 @@ config ARM64
 	select HAVE_PERF_EVENTS
 	select HAVE_PERF_REGS
 	select HAVE_PERF_USER_STACK_DUMP
+	select HAVE_REGS_AND_STACK_ACCESS_API
 	select HAVE_RCU_TABLE_FREE
 	select HAVE_SYSCALL_TRACEPOINTS
 	select IRQ_DOMAIN
diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index d6dd9fd..8f440e9 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -118,6 +118,8 @@ struct pt_regs {
 	u64 syscallno;
 };
 
+#define MAX_REG_OFFSET (sizeof(struct user_pt_regs) - sizeof(u64))
+
 #define arch_has_single_step()	(1)
 
 #ifdef CONFIG_COMPAT
@@ -146,6 +148,29 @@ struct pt_regs {
 #define user_stack_pointer(regs) \
 	(!compat_user_mode(regs) ? (regs)->sp : (regs)->compat_sp)
 
+/**
+ * regs_get_register() - get register value from its offset
+ * @regs:	   pt_regs from which register value is gotten
+ * @offset:    offset number of the register.
+ *
+ * regs_get_register returns the value of a register whose offset from @regs.
+ * The @offset is the offset of the register in struct pt_regs.
+ * If @offset is bigger than MAX_REG_OFFSET, this returns 0.
+ */
+static inline u64 regs_get_register(struct pt_regs *regs,
+					      unsigned int offset)
+{
+	if (unlikely(offset > MAX_REG_OFFSET))
+		return 0;
+	return *(u64 *)((u64)regs + offset);
+}
+
+/* Valid only for Kernel mode traps. */
+static inline unsigned long kernel_stack_pointer(struct pt_regs *regs)
+{
+	return regs->sp;
+}
+
 static inline unsigned long regs_return_value(struct pt_regs *regs)
 {
 	return regs->regs[0];
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index d882b83..f6199a5 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -48,6 +48,83 @@
 #define CREATE_TRACE_POINTS
 #include <trace/events/syscalls.h>
 
+#define ARM_pstate	pstate
+#define ARM_pc		pc
+#define ARM_sp		sp
+#define ARM_x30		regs[30]
+#define ARM_x29		regs[29]
+#define ARM_x28		regs[28]
+#define ARM_x27		regs[27]
+#define ARM_x26		regs[26]
+#define ARM_x25		regs[25]
+#define ARM_x24		regs[24]
+#define ARM_x23		regs[23]
+#define ARM_x22		regs[22]
+#define ARM_x21		regs[21]
+#define ARM_x20		regs[20]
+#define ARM_x19		regs[19]
+#define ARM_x18		regs[18]
+#define ARM_x17		regs[17]
+#define ARM_x16		regs[16]
+#define ARM_x15		regs[15]
+#define ARM_x14		regs[14]
+#define ARM_x13		regs[13]
+#define ARM_x12		regs[12]
+#define ARM_x11		regs[11]
+#define ARM_x10		regs[10]
+#define ARM_x9		regs[9]
+#define ARM_x8		regs[8]
+#define ARM_x7		regs[7]
+#define ARM_x6		regs[6]
+#define ARM_x5		regs[5]
+#define ARM_x4		regs[4]
+#define ARM_x3		regs[3]
+#define ARM_x2		regs[2]
+#define ARM_x1		regs[1]
+#define ARM_x0		regs[0]
+
+#define REG_OFFSET_NAME(r) \
+	{.name = #r, .offset = offsetof(struct pt_regs, ARM_##r)}
+#define REG_OFFSET_END {.name = NULL, .offset = 0}
+
+const struct pt_regs_offset regs_offset_table[] = {
+	REG_OFFSET_NAME(x0),
+	REG_OFFSET_NAME(x1),
+	REG_OFFSET_NAME(x2),
+	REG_OFFSET_NAME(x3),
+	REG_OFFSET_NAME(x4),
+	REG_OFFSET_NAME(x5),
+	REG_OFFSET_NAME(x6),
+	REG_OFFSET_NAME(x7),
+	REG_OFFSET_NAME(x8),
+	REG_OFFSET_NAME(x9),
+	REG_OFFSET_NAME(x10),
+	REG_OFFSET_NAME(x11),
+	REG_OFFSET_NAME(x12),
+	REG_OFFSET_NAME(x13),
+	REG_OFFSET_NAME(x14),
+	REG_OFFSET_NAME(x15),
+	REG_OFFSET_NAME(x16),
+	REG_OFFSET_NAME(x17),
+	REG_OFFSET_NAME(x18),
+	REG_OFFSET_NAME(x19),
+	REG_OFFSET_NAME(x20),
+	REG_OFFSET_NAME(x21),
+	REG_OFFSET_NAME(x22),
+	REG_OFFSET_NAME(x23),
+	REG_OFFSET_NAME(x24),
+	REG_OFFSET_NAME(x25),
+	REG_OFFSET_NAME(x26),
+	REG_OFFSET_NAME(x27),
+	REG_OFFSET_NAME(x28),
+	REG_OFFSET_NAME(x29),
+	REG_OFFSET_NAME(x30),
+	REG_OFFSET_NAME(sp),
+	REG_OFFSET_NAME(pc),
+	REG_OFFSET_NAME(pstate),
+	REG_OFFSET_END,
+};
+
 /*
  * TODO: does not yet catch signals sent when the child dies.
  * in exit.c or in signal.c.
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1205318

FromWill Deacon <will.deacon@arm.com>
Date2015-08-11 19:40 +0200
Message-ID<pWlGN-3z2-1@gated-at.bofh.it>
In reply to#1204662
Hi David,

On Tue, Aug 11, 2015 at 01:52:38AM +0100, David Long wrote:
> From: "David A. Long" <dave.long@linaro.org>
> 
> Add HAVE_REGS_AND_STACK_ACCESS_API feature for arm64.
> 
> Signed-off-by: David A. Long <dave.long@linaro.org>
> ---
>  arch/arm64/Kconfig              |  1 +
>  arch/arm64/include/asm/ptrace.h | 25 +++++++++++++
>  arch/arm64/kernel/ptrace.c      | 77 +++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 103 insertions(+)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 318175f..ef5d726 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -70,6 +70,7 @@ config ARM64
>  	select HAVE_PERF_EVENTS
>  	select HAVE_PERF_REGS
>  	select HAVE_PERF_USER_STACK_DUMP
> +	select HAVE_REGS_AND_STACK_ACCESS_API
>  	select HAVE_RCU_TABLE_FREE
>  	select HAVE_SYSCALL_TRACEPOINTS
>  	select IRQ_DOMAIN
> diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
> index d6dd9fd..8f440e9 100644
> --- a/arch/arm64/include/asm/ptrace.h
> +++ b/arch/arm64/include/asm/ptrace.h
> @@ -118,6 +118,8 @@ struct pt_regs {
>  	u64 syscallno;
>  };
>  
> +#define MAX_REG_OFFSET (sizeof(struct user_pt_regs) - sizeof(u64))

Can you not use offset_of(struct user_pt_regs, pstate) here?

> +
>  #define arch_has_single_step()	(1)
>  
>  #ifdef CONFIG_COMPAT
> @@ -146,6 +148,29 @@ struct pt_regs {
>  #define user_stack_pointer(regs) \
>  	(!compat_user_mode(regs) ? (regs)->sp : (regs)->compat_sp)
>  
> +/**
> + * regs_get_register() - get register value from its offset
> + * @regs:	   pt_regs from which register value is gotten
> + * @offset:    offset number of the register.
> + *
> + * regs_get_register returns the value of a register whose offset from @regs.
> + * The @offset is the offset of the register in struct pt_regs.
> + * If @offset is bigger than MAX_REG_OFFSET, this returns 0.
> + */
> +static inline u64 regs_get_register(struct pt_regs *regs,
> +					      unsigned int offset)
> +{
> +	if (unlikely(offset > MAX_REG_OFFSET))
> +		return 0;
> +	return *(u64 *)((u64)regs + offset);
> +}

Is this guaranteed only to be called on kernel-mode regs, or do we need
to deal with compat tasks too?

> +
> +/* Valid only for Kernel mode traps. */
> +static inline unsigned long kernel_stack_pointer(struct pt_regs *regs)
> +{
> +	return regs->sp;
> +}
> +
>  static inline unsigned long regs_return_value(struct pt_regs *regs)
>  {
>  	return regs->regs[0];
> diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
> index d882b83..f6199a5 100644
> --- a/arch/arm64/kernel/ptrace.c
> +++ b/arch/arm64/kernel/ptrace.c
> @@ -48,6 +48,83 @@
>  #define CREATE_TRACE_POINTS
>  #include <trace/events/syscalls.h>
>  
> +#define ARM_pstate	pstate
> +#define ARM_pc		pc
> +#define ARM_sp		sp
> +#define ARM_x30		regs[30]
> +#define ARM_x29		regs[29]
> +#define ARM_x28		regs[28]
> +#define ARM_x27		regs[27]
> +#define ARM_x26		regs[26]
> +#define ARM_x25		regs[25]
> +#define ARM_x24		regs[24]
> +#define ARM_x23		regs[23]
> +#define ARM_x22		regs[22]
> +#define ARM_x21		regs[21]
> +#define ARM_x20		regs[20]
> +#define ARM_x19		regs[19]
> +#define ARM_x18		regs[18]
> +#define ARM_x17		regs[17]
> +#define ARM_x16		regs[16]
> +#define ARM_x15		regs[15]
> +#define ARM_x14		regs[14]
> +#define ARM_x13		regs[13]
> +#define ARM_x12		regs[12]
> +#define ARM_x11		regs[11]
> +#define ARM_x10		regs[10]
> +#define ARM_x9		regs[9]
> +#define ARM_x8		regs[8]
> +#define ARM_x7		regs[7]
> +#define ARM_x6		regs[6]
> +#define ARM_x5		regs[5]
> +#define ARM_x4		regs[4]
> +#define ARM_x3		regs[3]
> +#define ARM_x2		regs[2]
> +#define ARM_x1		regs[1]
> +#define ARM_x0		regs[0]

I've said it before, but I really don't like these macros. I'd rather
rework the following REG_OFFSET_NAME to be GPR_OFFSET_NAME which could
prefix the "x" in the name field.

> +
> +#define REG_OFFSET_NAME(r) \
> +	{.name = #r, .offset = offsetof(struct pt_regs, ARM_##r)}
> +#define REG_OFFSET_END {.name = NULL, .offset = 0}
> +
> +const struct pt_regs_offset regs_offset_table[] = {
> +	REG_OFFSET_NAME(x0),
> +	REG_OFFSET_NAME(x1),
> +	REG_OFFSET_NAME(x2),
> +	REG_OFFSET_NAME(x3),
> +	REG_OFFSET_NAME(x4),
> +	REG_OFFSET_NAME(x5),
> +	REG_OFFSET_NAME(x6),
> +	REG_OFFSET_NAME(x7),
> +	REG_OFFSET_NAME(x8),
> +	REG_OFFSET_NAME(x9),
> +	REG_OFFSET_NAME(x10),
> +	REG_OFFSET_NAME(x11),
> +	REG_OFFSET_NAME(x12),
> +	REG_OFFSET_NAME(x13),
> +	REG_OFFSET_NAME(x14),
> +	REG_OFFSET_NAME(x15),
> +	REG_OFFSET_NAME(x16),
> +	REG_OFFSET_NAME(x17),
> +	REG_OFFSET_NAME(x18),
> +	REG_OFFSET_NAME(x19),
> +	REG_OFFSET_NAME(x20),
> +	REG_OFFSET_NAME(x21),
> +	REG_OFFSET_NAME(x22),
> +	REG_OFFSET_NAME(x23),
> +	REG_OFFSET_NAME(x24),
> +	REG_OFFSET_NAME(x25),
> +	REG_OFFSET_NAME(x26),
> +	REG_OFFSET_NAME(x27),
> +	REG_OFFSET_NAME(x28),
> +	REG_OFFSET_NAME(x29),
> +	REG_OFFSET_NAME(x30),

Does this interact badly with perf tools, which expect to pass "lr" for
x30? (see tools/perf/arch/arm64/include/perf_regs.h).

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1206495

FromDavid Long <dave.long@linaro.org>
Date2015-08-13 06:00 +0200
Message-ID<pWRQm-8uz-25@gated-at.bofh.it>
In reply to#1205318
On 08/11/15 13:31, Will Deacon wrote:
> Hi David,
>
> On Tue, Aug 11, 2015 at 01:52:38AM +0100, David Long wrote:
>> From: "David A. Long" <dave.long@linaro.org>
>>
>> Add HAVE_REGS_AND_STACK_ACCESS_API feature for arm64.
>>
>> Signed-off-by: David A. Long <dave.long@linaro.org>
>> ---
>>   arch/arm64/Kconfig              |  1 +
>>   arch/arm64/include/asm/ptrace.h | 25 +++++++++++++
>>   arch/arm64/kernel/ptrace.c      | 77 +++++++++++++++++++++++++++++++++++++++++
>>   3 files changed, 103 insertions(+)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 318175f..ef5d726 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -70,6 +70,7 @@ config ARM64
>>   	select HAVE_PERF_EVENTS
>>   	select HAVE_PERF_REGS
>>   	select HAVE_PERF_USER_STACK_DUMP
>> +	select HAVE_REGS_AND_STACK_ACCESS_API
>>   	select HAVE_RCU_TABLE_FREE
>>   	select HAVE_SYSCALL_TRACEPOINTS
>>   	select IRQ_DOMAIN
>> diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
>> index d6dd9fd..8f440e9 100644
>> --- a/arch/arm64/include/asm/ptrace.h
>> +++ b/arch/arm64/include/asm/ptrace.h
>> @@ -118,6 +118,8 @@ struct pt_regs {
>>   	u64 syscallno;
>>   };
>>
>> +#define MAX_REG_OFFSET (sizeof(struct user_pt_regs) - sizeof(u64))
>
> Can you not use offset_of(struct user_pt_regs, pstate) here?

Yes, "offsetof" actually though.  I've just made that change.

>> +
>>   #define arch_has_single_step()	(1)
>>
>>   #ifdef CONFIG_COMPAT
>> @@ -146,6 +148,29 @@ struct pt_regs {
>>   #define user_stack_pointer(regs) \
>>   	(!compat_user_mode(regs) ? (regs)->sp : (regs)->compat_sp)
>>
>> +/**
>> + * regs_get_register() - get register value from its offset
>> + * @regs:	   pt_regs from which register value is gotten
>> + * @offset:    offset number of the register.
>> + *
>> + * regs_get_register returns the value of a register whose offset from @regs.
>> + * The @offset is the offset of the register in struct pt_regs.
>> + * If @offset is bigger than MAX_REG_OFFSET, this returns 0.
>> + */
>> +static inline u64 regs_get_register(struct pt_regs *regs,
>> +					      unsigned int offset)
>> +{
>> +	if (unlikely(offset > MAX_REG_OFFSET))
>> +		return 0;
>> +	return *(u64 *)((u64)regs + offset);
>> +}
>
> Is this guaranteed only to be called on kernel-mode regs, or do we need
> to deal with compat tasks too?

If I understand the question I think it's fine that it only deals with 
kernel-mode registers.  The implemenation is functionally similar to the 
other five architectures that implement it.

>> +
>> +/* Valid only for Kernel mode traps. */
>> +static inline unsigned long kernel_stack_pointer(struct pt_regs *regs)
>> +{
>> +	return regs->sp;
>> +}
>> +
>>   static inline unsigned long regs_return_value(struct pt_regs *regs)
>>   {
>>   	return regs->regs[0];
>> diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
>> index d882b83..f6199a5 100644
>> --- a/arch/arm64/kernel/ptrace.c
>> +++ b/arch/arm64/kernel/ptrace.c
>> @@ -48,6 +48,83 @@
>>   #define CREATE_TRACE_POINTS
>>   #include <trace/events/syscalls.h>
>>
>> +#define ARM_pstate	pstate
>> +#define ARM_pc		pc
>> +#define ARM_sp		sp
>> +#define ARM_x30		regs[30]
>> +#define ARM_x29		regs[29]
>> +#define ARM_x28		regs[28]
>> +#define ARM_x27		regs[27]
>> +#define ARM_x26		regs[26]
>> +#define ARM_x25		regs[25]
>> +#define ARM_x24		regs[24]
>> +#define ARM_x23		regs[23]
>> +#define ARM_x22		regs[22]
>> +#define ARM_x21		regs[21]
>> +#define ARM_x20		regs[20]
>> +#define ARM_x19		regs[19]
>> +#define ARM_x18		regs[18]
>> +#define ARM_x17		regs[17]
>> +#define ARM_x16		regs[16]
>> +#define ARM_x15		regs[15]
>> +#define ARM_x14		regs[14]
>> +#define ARM_x13		regs[13]
>> +#define ARM_x12		regs[12]
>> +#define ARM_x11		regs[11]
>> +#define ARM_x10		regs[10]
>> +#define ARM_x9		regs[9]
>> +#define ARM_x8		regs[8]
>> +#define ARM_x7		regs[7]
>> +#define ARM_x6		regs[6]
>> +#define ARM_x5		regs[5]
>> +#define ARM_x4		regs[4]
>> +#define ARM_x3		regs[3]
>> +#define ARM_x2		regs[2]
>> +#define ARM_x1		regs[1]
>> +#define ARM_x0		regs[0]
>
> I've said it before, but I really don't like these macros. I'd rather
> rework the following REG_OFFSET_NAME to be GPR_OFFSET_NAME which could
> prefix the "x" in the name field.

OK, I've ripped that out and replaced REG_OFFSET_NAME with 
GPR_OFFSET_NAME, for the numbered registers.  I'm using REGS_OFFSET_NAME 
(defined for all architectures in my earlier cleanup patch) for the 
non-numbered registers.

>
>> +
>> +#define REG_OFFSET_NAME(r) \
>> +	{.name = #r, .offset = offsetof(struct pt_regs, ARM_##r)}
>> +#define REG_OFFSET_END {.name = NULL, .offset = 0}
>> +
>> +const struct pt_regs_offset regs_offset_table[] = {
>> +	REG_OFFSET_NAME(x0),
>> +	REG_OFFSET_NAME(x1),
>> +	REG_OFFSET_NAME(x2),
>> +	REG_OFFSET_NAME(x3),
>> +	REG_OFFSET_NAME(x4),
>> +	REG_OFFSET_NAME(x5),
>> +	REG_OFFSET_NAME(x6),
>> +	REG_OFFSET_NAME(x7),
>> +	REG_OFFSET_NAME(x8),
>> +	REG_OFFSET_NAME(x9),
>> +	REG_OFFSET_NAME(x10),
>> +	REG_OFFSET_NAME(x11),
>> +	REG_OFFSET_NAME(x12),
>> +	REG_OFFSET_NAME(x13),
>> +	REG_OFFSET_NAME(x14),
>> +	REG_OFFSET_NAME(x15),
>> +	REG_OFFSET_NAME(x16),
>> +	REG_OFFSET_NAME(x17),
>> +	REG_OFFSET_NAME(x18),
>> +	REG_OFFSET_NAME(x19),
>> +	REG_OFFSET_NAME(x20),
>> +	REG_OFFSET_NAME(x21),
>> +	REG_OFFSET_NAME(x22),
>> +	REG_OFFSET_NAME(x23),
>> +	REG_OFFSET_NAME(x24),
>> +	REG_OFFSET_NAME(x25),
>> +	REG_OFFSET_NAME(x26),
>> +	REG_OFFSET_NAME(x27),
>> +	REG_OFFSET_NAME(x28),
>> +	REG_OFFSET_NAME(x29),
>> +	REG_OFFSET_NAME(x30),
>
> Does this interact badly with perf tools, which expect to pass "lr" for
> x30? (see tools/perf/arch/arm64/include/perf_regs.h).
>

Possibly, I can test that when I'm back from my short vacation this 
week.  The lr/x30 thing seems to be a recurring issue.  Perhaps it is 
best simply to add a reundant entry for x30 as "lr".  It's simple enough 
to do, although just slightly ugly looking as it would have to be done 
without a macro.  Would one ever use "x31" in place of "sp"?

Conversions in the other direction would have to use one or the other of 
course.

> Will
>

-dl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1209152

FromWill Deacon <will.deacon@arm.com>
Date2015-08-18 11:40 +0200
Message-ID<pYLx8-2dp-1@gated-at.bofh.it>
In reply to#1206495
Hi David,

On Thu, Aug 13, 2015 at 04:50:40AM +0100, David Long wrote:
> On 08/11/15 13:31, Will Deacon wrote:
> > On Tue, Aug 11, 2015 at 01:52:38AM +0100, David Long wrote:
> >> +	REG_OFFSET_NAME(x30),
> >
> > Does this interact badly with perf tools, which expect to pass "lr" for
> > x30? (see tools/perf/arch/arm64/include/perf_regs.h).
> >
> 
> Possibly, I can test that when I'm back from my short vacation this 
> week.  The lr/x30 thing seems to be a recurring issue.  Perhaps it is 
> best simply to add a reundant entry for x30 as "lr".  It's simple enough 
> to do, although just slightly ugly looking as it would have to be done 
> without a macro.  Would one ever use "x31" in place of "sp"?

No; "sp" should always be "sp". Let me know how you get on with perf. I
couldn't quite tie the two ends together, but it does look like it expects
"lr" to work.

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web