arch: stack trace Kconfig & dependencies cleanup

[ycsin]

Overview

• Create CONFIG_ARM64_EXCEPTION_STACK_TRACE that depends on CONFIG_ARM64_ENABLE_FRAME_POINTER
• Move x86 specific Kconfig of CONFIG_EXCEPTION_STACK_TRACE to CONFIG_X86_EXCEPTION_STACK_TRACE
• CONFIG_EXCEPTION_STACK_TRACE now depends on architecture-specific EXCEPTION_STACK_TRACE Kconfig to be enabled
• Compile stack trace implementation only when user select CONFIG_EXCEPTION_STACK_TRACE

Current

RISC-V / X86

ARM64

This PR (all supported archs)

[dcpleung]

Hm... I think you can keep the arch specific kconfig without renaming them, or remove the arch specific ones entirely.

Also, might be a good idea to add a CONFIG_ARCH_HAS_EXCEPTION_STACK_TRACE so CONFIG_EXCEPTION_STACK_TRACE can depend on that, which eliminates the need to update the depend line in the future for other archs.

[ycsin]

Hm... I think you can keep the arch specific kconfig without renaming them, or remove the arch specific ones entirely.

Also, might be a good idea to add a CONFIG_ARCH_HAS_EXCEPTION_STACK_TRACE so CONFIG_EXCEPTION_STACK_TRACE can depend on that, which eliminates the need to update the depend line in the future for other archs.

Sounds like you kinda prefer #72863? But,

Hm... usually CONFIG_ARCH_HAS_* are enabled by select, so that they cannot be "disabled" by later kconfig entries.

select would force CONFIG_ARCH_HAS_EXCEPTION_STACK_TRACE to be on even if the dependencies are not met. In that case, where should I place the dependencies in your opinion?

Maybe a top-down approach?

• User enables CONFIG_EXCEPTION_STACK_TRACE
• CONFIG_X86_EXCEPTION_STACK_TRACE default y if CONFIG_EXCEPTION_STACK_TRACE
• CONFIG_X86_EXCEPTION_STACK_TRACE select all its dependencies?

[ycsin]

Moved back to draft for now, opened #73376 specifically for the cleanup

[dcpleung]

Hm... usually CONFIG_ARCH_HAS_* are enabled by select, so that they cannot be "disabled" by later kconfig entries.

select would force CONFIG_ARCH_HAS_EXCEPTION_STACK_TRACE to be on even if the dependencies are not met. In that case, where should I place the dependencies in your opinion?

Maybe a top-down approach?

• User enables CONFIG_EXCEPTION_STACK_TRACE
• CONFIG_X86_EXCEPTION_STACK_TRACE default y if CONFIG_EXCEPTION_STACK_TRACE
• CONFIG_X86_EXCEPTION_STACK_TRACE select all its dependencies?

I think that would be a better approach. A developer wants to enable such feature, so any dependencies should be pulled in. Or else one has to do dependency hunting through kconfig.

[ycsin]

Hm... usually CONFIG_ARCH_HAS_* are enabled by select, so that they cannot be "disabled" by later kconfig entries.

select would force CONFIG_ARCH_HAS_EXCEPTION_STACK_TRACE to be on even if the dependencies are not met. In that case, where should I place the dependencies in your opinion?
Maybe a top-down approach?

• User enables CONFIG_EXCEPTION_STACK_TRACE
• CONFIG_X86_EXCEPTION_STACK_TRACE default y if CONFIG_EXCEPTION_STACK_TRACE
• CONFIG_X86_EXCEPTION_STACK_TRACE select all its dependencies?

I think that would be a better approach. A developer wants to enable such feature, so any dependencies should be pulled in. Or else one has to do dependency hunting through kconfig.

There are some dependencies that can't be simply selected without getting more involved, like NO_OPTIMIZATIONS & !OMIT_FRAME_POINTER, so I'm going to keep this PR as-is, which will at least make the dependencies consistent across archs.

[andyross]

Still +1