Update stack_traces.md with frame-pointer unwinding info

Now that frame-pointer unwinding is supported for runtime stack traces, update the documentation.

Bug: 1203576
Change-Id: I05f9ea0c2a7dc8830e540df444ca5cf0e75bc3b2
Test: None
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/docs/+/2890017
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Eliot Courtney <edcourtney@chromium.org>
Tested-by: Eliot Courtney <edcourtney@chromium.org>
diff --git a/stack_traces.md b/stack_traces.md
index 2a2d688..56bad74 100644
--- a/stack_traces.md
+++ b/stack_traces.md
@@ -18,12 +18,17 @@
 
 ### How to build and deploy a Chrome that can print runtime stack traces
 
-#### Making sure `exclude_unwind_tables` is false
+#### Making sure `exclude_unwind_tables` is false or frame pointer unwinding works
 
 You can skip this section if you are not building an official build, i.e.
 not passing either `--internal` or `--official` to chrome-sdk, and not
 explicitly setting `is_official_build=true` in your gn arguments.
 
+You may also skip this section if frame pointer unwinding works on your
+platform. Currently all platforms support frame pointer unwinding,
+except ARM devices that use thumb instructions. See [compiler.gni] for
+more information.
+
 However, if you are building an official build then `exclude_unwind_tables`
 will be true by default. To add flags to gn args, you can either [add them via]
 `--gn-extra-args`:
@@ -43,6 +48,7 @@
 Then append `exclude_unwind_tables=false`.
 
 [add them via]: simple_chrome_workflow.md#cros-chrome_sdk-options
+[compiler.gni]: https://source.chromium.org/chromium/chromium/src/+/main:build/config/compiler/compiler.gni
 
 #### Deploying Chrome
 
@@ -162,7 +168,7 @@
 Sometimes stack traces are printed without being symbolized ("<unknown>").
 If this happens, there are a few things to check:
 
-1\. Check `exclude_unwind_tables` is false.
+1\. Check `exclude_unwind_tables` is false or frame-pointer unwinding works.
 
 2\. Check the process you are printing from isn't sandboxed.
 
@@ -194,6 +200,11 @@
 binary if you are building with symbol_level=1 or symbol_level=2. For stack
 trace purposes, symbol_level=1 should be enough.
 
+If frame pointer unwinding is supported, you may be able to print
+an unsymbolized stack trace. Unfortunately it is non-trivial to symbolize
+the trace afterwards (with only the trace information). It would require
+the memory map information, at least.
+
 | symbol_level | deploy_chrome arg |  size  | runtime traces? |
 |--------------|-------------------|--------|-----------------|
 | 2            | nostrip           | 1.7 GB | yes             |