ARM stack unwinding is upstream since 2009 and has been proven
working well. At this time it is the preferred stack unwinding
support since it also supports Thumb 2. Do not scare people
and drop the EXPERIMENTAL mark.
Signed-off-by: Stefan Agner <[email protected]>
---
arch/arm/Kconfig.debug | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index cb65cf67dfa2..ba2d94555e06 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -63,7 +63,7 @@ config FRAME_POINTER
reported is severely limited.
config ARM_UNWIND
- bool "Enable stack unwinding support (EXPERIMENTAL)"
+ bool "Enable stack unwinding support"
depends on AEABI
default y
help
--
2.18.0
On Sat, Aug 11, 2018 at 12:31:27PM +0200, Stefan Agner wrote:
> ARM stack unwinding is upstream since 2009 and has been proven
> working well. At this time it is the preferred stack unwinding
> support since it also supports Thumb 2. Do not scare people
> and drop the EXPERIMENTAL mark.
Actually, there are still cases where we're missing the annotations -
I've seen them in various oops dumps, but I forget where they are.
What I do remember is that they didn't seem trivial to fix at the
time, so it's still recommended that frame pointers are used if you
want to guarantee getting a debuggable oops dump.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up
According to speedtest.net: 13Mbps down 490kbps up
On 11.08.2018 18:57, Russell King - ARM Linux wrote:
> On Sat, Aug 11, 2018 at 12:31:27PM +0200, Stefan Agner wrote:
>> ARM stack unwinding is upstream since 2009 and has been proven
>> working well. At this time it is the preferred stack unwinding
>> support since it also supports Thumb 2. Do not scare people
>> and drop the EXPERIMENTAL mark.
>
> Actually, there are still cases where we're missing the annotations -
> I've seen them in various oops dumps, but I forget where they are.
> What I do remember is that they didn't seem trivial to fix at the
> time, so it's still recommended that frame pointers are used if you
> want to guarantee getting a debuggable oops dump.
Ok, but does that warrants the experimental mark?
Experimental sounds rather harsh to me. People might disable it because
of that... I'd rather have a >90% chance of having a good stack trace
than none at all.
--
Stefan