On 08.07.2025 22:11, Steven Rostedt wrote:
> On Tue, 8 Jul 2025 15:58:56 -0400
> Mathieu Desnoyers <mathieu.desnoy...@efficios.com> wrote:
>
>>> @@ -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
jre...@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/
