[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a5c67047-94d9-482b-892b-ef1662d2fe65@linux.ibm.com>
Date: Wed, 23 Oct 2024 15:22:35 +0200
From: Jens Remus <jremus@...ux.ibm.com>
To: Josh Poimboeuf <jpoimboe@...nel.org>
Cc: Peter Zijlstra <peterz@...radead.org>,
Steven Rostedt <rostedt@...dmis.org>, Ingo Molnar <mingo@...nel.org>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
linux-kernel@...r.kernel.org, Indu Bhagat <indu.bhagat@...cle.com>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...nel.org>, Namhyung Kim <namhyung@...nel.org>,
Ian Rogers <irogers@...gle.com>,
Adrian Hunter <adrian.hunter@...el.com>,
linux-perf-users@...r.kernel.org, Mark Brown <broonie@...nel.org>,
linux-toolchains@...r.kernel.org, Jordan Rome <jordalgo@...a.com>,
Sam James <sam@...too.org>, x86@...nel.org,
Heiko Carstens <hca@...ux.ibm.com>,
Ilya Leoshkevich <iii@...ux.ibm.com>,
Vasily Gorbik <gor@...ux.ibm.com>
Subject: Re: [PATCH v2 00/11] unwind, perf: sframe user space unwinding,
deferred perf callchains
Hello Josh!
On 14.09.2024 01:02, Josh Poimboeuf wrote:
> This is a new version of sframe user space unwinding + perf deferred
> callchains. Better late than never.
...
> These patches add support for unwinding user space from the kernel using
> SFrame with perf. It should be easy to add user unwinding support for
> other components like ftrace.
...
We are looking forward to implement support for unwinding of user space
using SFrame in kernel/perf on s390. One major concern is that your x86
implementation currently relies on a fallback to unwinding using frame
pointer. On s390 unwinding using frame pointer is unsupported, because
of lack of proper s390x ABI [1] specification and compiler support. In
theory there would be a s390-specific alternative of unwinding using
backchain (compiler option -mbackchain), but this has limitations and
there is currently no distribution where user space is built with
backchain.
How much of an issue would it be if s390 could not provide an unwinding
fallback implementation? Do you see the possibility to get away without?
For s390 support of unwinding using SFrame we would need to make a few
changes to your generic unwinding framework in the kernel:
- Support for architectures that do not define CFA == SP at callsite:
On s390 the CFA is defined as SP at callsite +160. The stack pointer
(SP) therefore unwinds as SP = CFA - 160. For that we would introduce
e.g. a sp_val_off field (SP value offset from CFA) in struct
user_unwind_frame that would default to 0 on all architectures except
s390.
- Support for architectures where RA is not necessarily saved on stack:
On s390 the return address (RA) is not saved (on stack) at function
entry. In leaf functions it is not necessarily saved at all.
- Support for architectures were RA/FP are saved in registers in leaf
functions:
On s390 the frame pointer (FP) and return address (RA) registers can
be saved in other registers when in leaf functions. In the SFrame
format we would encode the DWARF register number as offset using the
least-significant bit as indication: offset = (regnum << 1) | 1.
Therefore we would need to extend your generic unwinding framework to
support FP and RA to be restored from registers.
[1]: s390x ELF ABI supplement,
https://github.com/IBM/s390x-abi/releases
Thanks and regards,
Jens
--
Jens Remus
Linux on Z Development (D3303) and z/VSE Support
+49-7031-16-1128 Office
jremus@...ibm.com
IBM
IBM Deutschland Research & Development GmbH; Vorsitzender des
Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der
Gesellschaft: Böblingen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/
Powered by blists - more mailing lists