runtime: allow panic on syscall.Exit instead of halting #4010
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In some environments, such as u-root, code can be imported which provides a shell. The shell calls functions, instead of trying to use exec.Command (which is not available). An example can be found in github.com:u-root/u-root/tools/tinygobb.
When the command exits, the shell needs to resume operation, which is not possible when runtime.Exit calls halt.
On tamago, we achieve this by setting a normally nil function, runtime.Exit, to a funtion which panics. The shell has a recover() to catch the panics.
There are many ways in which setting runtime.Exit can go wrong, including different functions setting it to different functions.
tinygo allows a simpler, and hence more robust, model: instead of halting, we can panic. But in most cases, halting is ok.
Add a function, runtime.PanicOnExit, which enables a panic on exit. This function is idempotent, and once panic on exit is enabled, it can not be disabled. This is restrictive by design. It is hoped that by making it simple and non-revocable, we can avoid the problems that can occur with more complex mechanisms, but still provide an option to halting.
A function is provided, instead of just a variable, to allow simpler access from assembly, i.e., both variables and functions have been used in bare metal environments and, for several reasons, functions have proved more flexible.