Re: [PATCH 1/3] perf tests: Introduce perf_regs_load function on ARM64

[Jean Pihet]

Hi WIll, Mark,

Ping on this series. Can you please check? Is the refreshed patch OK?

Cheers,
Jean


On 28 April 2014 15:12, Jean Pihet <jean.pihet@xxxxxxxxxx> wrote:
> Introducing perf_regs_load function, which is going
> to be used for dwarf unwind test in following patches.
>
> It takes single argument as a pointer to the regs dump
> buffer and populates it with current registers values, as
> expected by the perf built-in unwinding test.
>
> Signed-off-by: Jean Pihet <jean.pihet@xxxxxxxxxx>
> Cc: Steve Capper <steve.capper@xxxxxxxxxx>
> Cc: Corey Ashford <cjashfor@xxxxxxxxxxxxxxxxxx>
> Cc: Frederic Weisbecker <fweisbec@xxxxxxxxx>
> Cc: Ingo Molnar <mingo@xxxxxxxxxx>
> Cc: Namhyung Kim <namhyung@xxxxxxxxxx>
> Cc: Paul Mackerras <paulus@xxxxxxxxx>
> Cc: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>
> Cc: Arnaldo Carvalho de Melo <acme@xxxxxxxxxxxxxxxxxx>
> Cc: David Ahern <dsahern@xxxxxxxxx>
> Cc: Jiri Olsa <jolsa@xxxxxxxxxx>
> ---
>  tools/perf/arch/arm64/Makefile            |  1 +
>  tools/perf/arch/arm64/include/perf_regs.h |  2 ++
>  tools/perf/arch/arm64/tests/regs_load.S   | 40 +++++++++++++++++++++++++++++++
>  3 files changed, 43 insertions(+)
>  create mode 100644 tools/perf/arch/arm64/tests/regs_load.S
>
> diff --git a/tools/perf/arch/arm64/Makefile b/tools/perf/arch/arm64/Makefile
> index 67e9b3d..9b8f87e 100644
> --- a/tools/perf/arch/arm64/Makefile
> +++ b/tools/perf/arch/arm64/Makefile
> @@ -4,4 +4,5 @@ LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/dwarf-regs.o
>  endif
>  ifndef NO_LIBUNWIND
>  LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/unwind-libunwind.o
> +LIB_OBJS += $(OUTPUT)arch/$(ARCH)/tests/regs_load.o
>  endif
> diff --git a/tools/perf/arch/arm64/include/perf_regs.h b/tools/perf/arch/arm64/include/perf_regs.h
> index 2359546..1e052f1 100644
> --- a/tools/perf/arch/arm64/include/perf_regs.h
> +++ b/tools/perf/arch/arm64/include/perf_regs.h
> @@ -9,6 +9,8 @@
>  #define PERF_REG_IP    PERF_REG_ARM64_PC
>  #define PERF_REG_SP    PERF_REG_ARM64_SP
>
> +void perf_regs_load(u64 *regs);
> +
>  static inline const char *perf_reg_name(int id)
>  {
>         switch (id) {
> diff --git a/tools/perf/arch/arm64/tests/regs_load.S b/tools/perf/arch/arm64/tests/regs_load.S
> new file mode 100644
> index 0000000..40b8b99
> --- /dev/null
> +++ b/tools/perf/arch/arm64/tests/regs_load.S
> @@ -0,0 +1,40 @@
> +#include <linux/linkage.h>
> +
> +/*
> + * Implementation of void perf_regs_load(u64 *regs);
> + *
> + * This functions fills in the 'regs' buffer from the actual registers values,
> + * in the way the perf built-in unwinding test expects them, e.g. an address
> + * within the caller:
> + * - the PC at the time at the call to this function. Since this function
> + *   is called using a bl instruction, the PC value is taken from LR,
> + * - the current SP (not touched by this function),
> + * - the current value of LR is merely retrieved and stored because the
> + *   value before the call to this function is unknown at this time; it will
> + *   be unwound from the dwarf information in unwind__get_entries.
> + */
> +
> +.text
> +.type perf_regs_load,%function
> +ENTRY(perf_regs_load)
> +       stp x0,  x1,  [x0], #16 // store x0..x29
> +       stp x2,  x3,  [x0], #16
> +       stp x4,  x5,  [x0], #16
> +       stp x6,  x7,  [x0], #16
> +       stp x8,  x9,  [x0], #16
> +       stp x10, x11, [x0], #16
> +       stp x12, x13, [x0], #16
> +       stp x14, x15, [x0], #16
> +       stp x16, x17, [x0], #16
> +       stp x18, x19, [x0], #16
> +       stp x20, x21, [x0], #16
> +       stp x22, x23, [x0], #16
> +       stp x24, x25, [x0], #16
> +       stp x26, x27, [x0], #16
> +       stp x28, x29, [x0], #16
> +       mov x1,  sp
> +       stp x30, x1,  [x0], #16 // store lr and sp
> +       str x30, [x0]           // store lr as the PC in order to skip the call
> +                               //  to this function
> +       ret
> +ENDPROC(perf_regs_load)
> --
> 1.7.11.7
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/