On 2025-07-09 10:06, Steven Rostedt wrote:
On Wed, 9 Jul 2025 09:51:09 -0400
Mathieu Desnoyers [off-list ref] wrote:
quoted
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.
Indeed it's only kernel internal API, but this is API that will be
expected by each architecture supporting unwind_user. Changing
this later on will cause a lot of friction and cross-architecture churn
compared to doing it right in the first place.
Thanks,
Mathieu
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
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com