Re: [PATCH v8 06/12] unwind_user/sframe: Wire up unwind_user to sframe

[Steven Rostedt <rostedt@goodmis.org>]

On Wed, 9 Jul 2025 09:51:09 -0400
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:

> One use-case for giving the "current_type" to iteration callers is to
> let end users know whether they should trust the frame info. If it
> comes from sframe, then it should be pretty solid. However, if it comes
> from frame pointers used as a fallback on a system that omits frame
> pointers, the user should consider the resulting data with a high level
> of skepticism.

That would be in the trace sent to the callback. We could add something
like the '?' if it's not trusted.

But for now, until we have a use case that we are implementing, I want
to keep this simple, otherwise it will never get done. I don't want to
add features for hypothetical scenarios.

Currently, the traceback is just an array of addresses. But this could
change in the future. What we are discussing right now is the internal
functionality of the user unwind code where I have made most of theses
functions static.

The only external functions that get called during the iteration is the
architecture specific code. If that code needs to know the difference
between sframes and frame pointers then we can modify it, but until
then, I rather keep this as is.

Jens, is there something that the architecture code needs now? If so,
then lets fix it, otherwise lets do it when there is something. This
isn't user API, it can change in the future.

-- Steve