On 09.07.2025 15:51, Mathieu Desnoyers wrote:
On 2025-07-09 09:46, Mathieu Desnoyers wrote:
quoted
I concur with Jens. I think we should keep track of both:
1) available unwind methods,
2) unwind method used for the current frame.
E.g.:
/*
* unwind types, listed in priority order: lower numbers are
* attempted first if available.
*/
enum unwind_user_type_bits {
UNWIND_USER_TYPE_SFRAME_BIT = 0,
UNWIND_USER_TYPE_FP_BIT = 1,
UNWIND_USER_TYPE_COMPAT_FP_BIT = 2,
_NR_UNWIND_USER_TYPE_BITS,
};
enum unwind_user_type {
UNWIND_USER_TYPE_NONE = 0,
UNWIND_USER_TYPE_SFRAME = (1U << UNWIND_USER_TYPE_SFRAME_BIT),
UNWIND_USER_TYPE_FP = (1U << UNWIND_USER_TYPE_FP_BIT),
UNWIND_USER_TYPE_COMPAT_FP = (1U << UNWIND_USER_TYPE_COMPAT_FP_BIT),
};
And have the following fields in struct unwind_user_state:
/* Unwind time used for the most recent unwind traversal iteration. */
enum unwind_user_type current_type;
/* Unwind types available in the current context. Bitmask of enum unwind_user_type. */
unsigned int available_types;
So as we end up adding stuff like registered JIT unwind info, we will
want to expand the "available types". And it makes sense to both keep
track of all available types (as a way to quickly know which mechanisms
we need to query for the current task) *and* to let the caller know
which unwind type was used for the current frame.
And AFAIU we'd be inserting a "jit unwind info" type between SFRAME and FP in
the future, because the jit unwind info would be more reliable than FP. This
would require that we bump the number for FP and COMPAT_FP, but that would
be OK because this is not ABI.
Thoughts ?
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.
The current_type may be different for every unwind step (frame). So
struct unwind_stacktrace would probably need the following added:
/* Unwind types used for taking the stack trace. */
unsigned int used_types;
So that the user of unwind_user() could decide whether to trust the
stack trace. But as Steve suggested in his reply, all of this could
be added later, once there is a need.
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/