Closed andreaspirklbauer closed 4 years ago
(Oops, I was not aware I could unfollow notifications of my own repositories... Fixed that.)
Yeah, that is even another option. Might be hard to combine this with https://github.com/schierlm/Oberon2013Modifications/tree/master/TrapBacktrace, though (as you would effectively have to store most of the stack instead of just one value).
I do not understand from the README file of TrapBacktrace how to combine it with DoubleTrap.
Apply the patches in this order:
patch <DoubleTrap/DoubleTrap.patch
patch <TrapBacktrace/PREPATCH_after_DoubleTrap.patch
patch <TrapBacktrace/TrapBacktrace.patch
patch <TrapBacktrace/POSTPATCH_after_DoubleTrap.patch
Next update will include a script to apply all modifications (that make sense in combination), and I will also include the resulting .Mod
files in the Releases section.
Release with most modifications is available now: https://github.com/schierlm/Oberon2013Modifications/releases/tag/2019.12
As I do not plan to implement your DoubleTrap way due to its interference with backtraces, closing this issue now.
When introducing a flag to detect whether the trap handler is being re-entered, one can save the current (trap) location in a global variable, so that the Oberon task that is executed after the next garbage collection cycle can still access it (albeit only of the trap that was caused BEFORE re-entering the trap routine.. but better than nothing). See the EO implementation.