On 08.07.2025 22:11, Steven Rostedt wrote:
On Tue, 8 Jul 2025 15:58:56 -0400
Mathieu Desnoyers [off-list ref] wrote:
quoted
quoted
@@ -111,6 +128,8 @@ static int unwind_user_start(struct unwind_user_state *state)
if (IS_ENABLED(CONFIG_HAVE_UNWIND_USER_COMPAT_FP) && in_compat_mode(regs))
state->type = UNWIND_USER_TYPE_COMPAT_FP;
+ else if (current_has_sframe())
+ state->type = UNWIND_USER_TYPE_SFRAME;
I think you'll want to update the state->type during the
traversal (in next()), because depending on whether
sframe is available for a given memory area of code
or not, the next() function can use either frame pointers
or sframe during the same traversal. It would be good
to know which is used after each specific call to next().
From my understanding this sets up what is available for the task at the
beginning.
So once we say "this task has sframes" it will try to use it every time. In
next we have:
if (compat_fp_state(state)) {
frame = &compat_fp_frame;
} else if (sframe_state(state)) {
/* sframe expects the frame to be local storage */
frame = &_frame;
if (sframe_find(state->ip, frame)) {
if (!IS_ENABLED(CONFIG_HAVE_UNWIND_USER_FP))
goto done;
frame = &fp_frame;
}
} else if (fp_state(state)) {
frame = &fp_frame;
} else {
goto done;
}
Where if sframe_find() fails and we switch over to frame pointers, if frame
pointers works, we can continue. But the next iteration, where the frame
pointer finds the previous ip, that ip may be in the sframe section again.
I've seen this work with my trace_printk()s. A function from code that is
running sframes calls into a library function that has frame pointers. The
walk walks through the frame pointers in the library, and when it hits the
code that has sframes, it starts using that again.
I think Mathieu has a point, as unwind_user_next() calls the optional
architecture-specific arch_unwind_user_next() at the end. The x86
implementation does state->type specific processing (for
UNWIND_USER_TYPE_COMPAT_FP).
If we switched the state to just FP, it will never try to use sframes.
So this state is more about "what does this task have" than what was used
per iteration.
While there is currently no fallback to UNWIND_USER_TYPE_COMPAT_FP that
would strictly require this, it could be useful to have both information.
Or the logic in unwind_user_start(), unwind_user_next(), and *_state()
may need to be adjusted so that state->type reflects the currently used
method, which unwind_user_next() determines and sets anew for every step.
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/