schierlm / Oberon2013Modifications

Modifications (I deliberately do not call them enhancements) I did to Project Oberon 2013.
Other
13 stars 5 forks source link

DoubleTrap with trap information in deferred trap handler #1

Closed andreaspirklbauer closed 4 years ago

andreaspirklbauer commented 4 years ago

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.

schierlm commented 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).

andreaspirklbauer commented 4 years ago

I do not understand from the README file of TrapBacktrace how to combine it with DoubleTrap.

schierlm commented 4 years ago

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.

schierlm commented 4 years ago

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.