Fix stack trace unwinding when inside a continuation

[kylefleming]

Fixes stack trace unwinding with gdb when inside a continuation.

Gdb walks back through the stack finding the return address and checks the instructions in the prologue of each function to see what the function is doing with the return address. Currently, I think there is a bug in the xtensa-gdb stack trace unwinding code where if it can't determine exactly what's going on with the return address in the prologue, then it looks at the a0 register; however, it doesn't seem to be updating the a0 register properly with each frame as it traces up the call stack. This leads to the behavior where once it hits cont_run (or another function that is creating a virtual stack and pretending to be the top function), it shows the frame 1 function as the next one up, instead of ending at cont_run. This is because frame 0's a0 is frame 1, so if a0 is never updated, then once it hits cont_run, it'll think a0 is cont_run's return address. It then uses the function at a0 to check the stack offset in a0's prologue and then using that offset to offset the stack of the cont_run frame, leading to garbage results after that.

This is an example of the current behavior:

#0  0x4000e235 in ?? ()
#1  0x40106698 in millis () at /Users/kyle/.platformio/packages/framework-arduinoespressif8266/cores/esp8266/core_esp8266_wiring.c:67
#2  0x402031e2 in loop () at src/WifiTesting.cpp:711
#3  0x40201ca0 in loop_wrapper () at /Users/kyle/.platformio/packages/framework-arduinoespressif8266/cores/esp8266/core_esp8266_main.cpp:123
#4  0x40202b78 in cont_run () at /Users/kyle/.platformio/packages/framework-arduinoespressif8266/cores/esp8266/cont.S:105
#5  0x40106698 in millis () at /Users/kyle/.platformio/packages/framework-arduinoespressif8266/cores/esp8266/core_esp8266_wiring.c:67

The change in the PR is to create a dummy wrapper that sets a0 to 0 in its prologue, signaling to gdb and other stack unwinding logic that this cont_wrapper function wants to be seen as the top level function. See this comment in xtensa-gdb. cont_wrapper uses a hardcoded label to return since it will always return to the same place. This allows us to clobber a0 safely.

Here's what it looks like after this change:

#0  0x4000e243 in ?? ()
#1  0x401011d0 in millis () at /Users/kyle/.platformio/packages/framework-arduinoespressif8266/cores/esp8266/core_esp8266_wiring.c:67
#2  0x40203221 in loop () at src/WifiTesting.cpp:595
#3  0x40201c90 in loop_wrapper () at /Users/kyle/.platformio/packages/framework-arduinoespressif8266/cores/esp8266/core_esp8266_main.cpp:123
#4  0x40202b31 in cont_wrapper () at /Users/kyle/.platformio/packages/framework-arduinoespressif8266/cores/esp8266/cont.S:80

[igrr]

Instead of creating a wrapper function, can we create a dummy stack frame at the top of the new stack? This can be done once in cont_init, I think.

[kylefleming]

I tried that in a bunch of different ways but kept running into the same problem. The gdb stack unwinding code seems to abort looking at the stack for the return address if it's not able to ascertain it from the prologue code. I think it's trying to be a little too smart, so just adding a dummy frame doesn't seem to work the way I would expect it to. The reason this wrapper technique works is that it's a well-formatted case of the setting the return address to 0 in the prologue, which seems to be the only case that gdb recognizes. I think if the a0 bug I mentioned above is fixed, this won't be necessary.

[devyte]

I have been wondering about that garbage output for the longest time. Thank you for figuring it out!

[igrr]

Thanks for explaining @kylefleming, makes sense.

Changes look good to me. I've marked the PR for 2.5.0 milestone since we are only merging fixes for critical issues before 2.4.1, which should be released soon.