On Thu, Nov 27, 2025 at 05:51:47PM +0100, Jens Remus wrote:

On 11/25/2025 5:43 PM, Jens Remus wrote:

quoted

This simplifies the code.   unwind_user_next_fp() does not need to
return -EINVAL if config option HAVE_UNWIND_USER_FP is disabled, as
unwind_user_start() will then not select this unwind method and
unwind_user_next() will therefore not call it.

Note that enabling the config option HAVE_UNWIND_USER_FP without
defining ARCH_INIT_USER_FP_FRAME, ARCH_INIT_USER_FP_ENTRY_FRAME, and
unwind_user_at_function_start() will result in a compile error, which
is helpful when implementing support for unwind user fp in an
architecture.

Signed-off-by: Jens Remus <redacted>

quoted

diff --git a/include/linux/unwind_user.h b/include/linux/unwind_user.h

quoted

@@ -5,9 +5,17 @@
 #include <linux/unwind_user_types.h>
 #include <asm/unwind_user.h>
 
-#ifndef ARCH_INIT_USER_FP_FRAME
- #define ARCH_INIT_USER_FP_FRAME
-#endif
+#ifndef CONFIG_HAVE_UNWIND_USER_FP
+
+#define ARCH_INIT_USER_FP_FRAME
+#define ARCH_INIT_USER_FP_ENTRY_FRAME

Will fix this as follows in the next version:

#define ARCH_INIT_USER_FP_FRAME(ws)
#define ARCH_INIT_USER_FP_ENTRY_FRAME(ws)

quoted

+
+static inline bool unwind_user_at_function_start(struct pt_regs *regs)
+{
+	return false;
+}

Would it be better to provide a generic dummy implementation (see below)
or should each arch implement that if it cannot tell whether the topmost
frame is at function start? If so, would it move from linux/unwind_user.h
to asm-generic/unwind_user.h?  Either way it would need to be outside of
the !CONFIG_HAVE_UNWIND_USER_FP guard.

I suppose a common fallback would be fine.