linux-trace-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jens Remus <jremus@linux.ibm.com>
To: Josh Poimboeuf <jpoimboe@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
	bpf@vger.kernel.org, x86@kernel.org,
	Steven Rostedt <rostedt@kernel.org>,
	Heiko Carstens <hca@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Ilya Leoshkevich <iii@linux.ibm.com>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>, Jiri Olsa <jolsa@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andrii Nakryiko <andrii@kernel.org>,
	Indu Bhagat <indu.bhagat@oracle.com>,
	"Jose E. Marchesi" <jemarch@gnu.org>,
	Beau Belgrave <beaub@linux.microsoft.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jens Axboe <axboe@kernel.dk>, Florian Weimer <fweimer@redhat.com>,
	Sam James <sam@gentoo.org>
Subject: Re: [RFC PATCH v1 06/16] unwind_user: Enable archs that define CFA = SP_callsite + offset
Date: Thu, 17 Jul 2025 11:27:45 +0200	[thread overview]
Message-ID: <ae46c02a-d871-4b26-97f4-bd82361ab8bc@linux.ibm.com> (raw)
In-Reply-To: <qoiocmdhuuaox5v5ig2ui67qbuxkvzl4z3ft4gdp7p3c4b4zfq@trjthmmculkf>

On 16.07.2025 23:32, Josh Poimboeuf wrote:
> On Thu, Jul 10, 2025 at 06:35:12PM +0200, Jens Remus wrote:
>> Most architectures define their CFA as the value of the stack pointer
>> (SP) at the call site in the previous frame, as suggested by the DWARF
>> standard:
>>
>>   CFA = <SP at call site>
>>
>> Enable unwinding of user space for architectures, such as s390, which
>> define their CFA as the value of the SP at the call site in the previous
>> frame with an offset:
>>
>>   CFA = <SP at call site> + offset
> 
> This is a bit confusing, as the comment and code define it as
> 
>     SP = CFA + offset
> 
> Should the commit log be updated to match that?

I agree that the commit message is confusing. Would it help if I replace
it with the following:

Most architectures define their CFA as the value of the stack pointer
(SP) at the call site in the previous frame, as suggested by the DWARF
standard.  Therefore the SP at call site can be unwound using an
implicitly assumed value offset from CFA rule with an offset of zero:

  .cfi_val_offset <SP>, 0

As a result the SP at call site computes as follows:

  SP = CFA

Enable unwinding of user space for architectures, such as s390, which
define their CFA as the value of the SP at the call site in the previous
frame with an offset.  Do so by enabling architectures to override the
default SP value offset from CFA of zero with an architecture-specific
one:

  .cfi_val_offset <SP>, offset
  
So that the SP at call site computes as follows:

  SP = CFA + offset

>> +++ b/arch/x86/include/asm/unwind_user.h
>> @@ -8,6 +8,7 @@
>>  	.cfa_off	= (s32)sizeof(long) *  2,				\
>>  	.ra_off		= (s32)sizeof(long) * -1,				\
>>  	.fp_off		= (s32)sizeof(long) * -2,				\
>> +	.sp_val_off	= (s32)0,						\
> 
> IIUC, this is similar to ra_off and fp_off in that its an offset from
> the CFA.  Can we call it "sp_off"?

My intent was to use the terminology from DWARF CFI (i.e. "offset(N)"
and "val_offset(N)") and the related assembler CFI directives:

  .cfi_offset register, offset:  Previous value of register is saved at
                                 offset from CFA.

  .cfi_val_offset register, offset:  Previous value of register is
                                     CFA + offset. 

Regards,
Jens
-- 
Jens Remus
Linux on Z Development (D3303)
+49-7031-16-1128 Office
jremus@de.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/


  reply	other threads:[~2025-07-17  9:29 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-10 16:35 [RFC PATCH v1 00/16] s390: SFrame user space unwinding Jens Remus
2025-07-10 16:35 ` [RFC PATCH v1 01/16] fixup! unwind_user: Add frame pointer support Jens Remus
2025-07-10 16:35 ` [RFC PATCH v1 02/16] s390: asm/dwarf.h should only be included in assembly files Jens Remus
2025-07-10 16:35 ` [RFC PATCH v1 03/16] s390/vdso: Avoid emitting DWARF CFI for non-vDSO Jens Remus
2025-07-10 16:35 ` [RFC PATCH v1 04/16] s390/vdso: Enable SFrame generation in vDSO Jens Remus
2025-07-10 16:35 ` [RFC PATCH v1 05/16] s390/vdso: Keep function symbols " Jens Remus
2025-07-10 16:35 ` [RFC PATCH v1 06/16] unwind_user: Enable archs that define CFA = SP_callsite + offset Jens Remus
2025-07-16 21:32   ` Josh Poimboeuf
2025-07-17  9:27     ` Jens Remus [this message]
2025-07-18  4:51       ` Josh Poimboeuf
2025-07-10 16:35 ` [RFC PATCH v1 07/16] unwind_user: Enable archs that do not necessarily save RA Jens Remus
2025-07-16 23:01   ` Josh Poimboeuf
2025-07-17 11:09     ` Jens Remus
2025-07-18  8:28       ` Jens Remus
2025-07-18 16:59         ` Josh Poimboeuf
2025-07-21 14:25           ` Jens Remus
2025-07-10 16:35 ` [RFC PATCH v1 08/16] unwind_user: Enable archs that save RA/FP in other registers Jens Remus
2025-07-17  2:01   ` Josh Poimboeuf
2025-07-17  2:50     ` Josh Poimboeuf
2025-07-17 12:07       ` Jens Remus
2025-07-18  4:52         ` Josh Poimboeuf
2025-07-17  3:57     ` Steven Rostedt
2025-07-17  7:24       ` Josh Poimboeuf
2025-07-17 12:05         ` Steven Rostedt
2025-07-17 11:28     ` Jens Remus
2025-07-17 12:10       ` Steven Rostedt
2025-07-18  4:51       ` Josh Poimboeuf
2025-07-10 16:35 ` [RFC PATCH v1 09/16] unwind_user/sframe: Enable archs with encoded SFrame CFA offsets Jens Remus
2025-07-10 16:35 ` [RFC PATCH v1 10/16] s390/ptrace: Enable HAVE_USER_RA_REG Jens Remus
2025-07-10 16:35 ` [RFC PATCH v1 11/16] s390/unwind_user/sframe: Enable HAVE_UNWIND_USER_SFRAME Jens Remus
2025-08-01 12:53   ` Heiko Carstens
2025-08-01 15:46     ` Jens Remus
2025-07-10 16:35 ` [RFC PATCH v1 12/16] unwind_user/backchain: Introduce back chain user space unwinding Jens Remus
2025-07-17  2:06   ` Josh Poimboeuf
2025-07-17 12:20     ` Jens Remus
2025-07-18  5:19       ` Josh Poimboeuf
2025-08-01 12:36         ` Heiko Carstens
2025-08-01 15:49           ` Jens Remus
2025-07-10 16:35 ` [RFC PATCH v1 13/16] s390/unwind_user/backchain: Enable HAVE_UNWIND_USER_BACKCHAIN Jens Remus
2025-07-10 16:35 ` [RFC PATCH v1 14/16] PREREQ: x86/asm: Avoid emitting DWARF CFI for non-VDSO Jens Remus
2025-07-10 16:35 ` [RFC PATCH v1 15/16] PREREQ: x86/vdso: Enable sframe generation in VDSO Jens Remus
2025-07-10 16:35 ` [RFC PATCH v1 16/16] WIP: fixup! s390/unwind_user/sframe: Enable HAVE_UNWIND_USER_SFRAME Jens Remus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ae46c02a-d871-4b26-97f4-bd82361ab8bc@linux.ibm.com \
    --to=jremus@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=andrii@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=beaub@linux.microsoft.com \
    --cc=bpf@vger.kernel.org \
    --cc=fweimer@redhat.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=iii@linux.ibm.com \
    --cc=indu.bhagat@oracle.com \
    --cc=jemarch@gnu.org \
    --cc=jolsa@kernel.org \
    --cc=jpoimboe@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=mingo@kernel.org \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@kernel.org \
    --cc=sam@gentoo.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).