Re: BREAKing into Euphoria
- Posted by ghaberek (admin) Feb 26, 2022
- 1421 views
What's the easiest way to contribute the TraceOn functionality patches to euphoria 4.1 source?
If this is something you want to implement, you are welcome to open a pull request against the Euphoria repo on GitHub. However, I'll warn you now that your method of using assembly code to inject tracing into the code stack is not going to be accepted. It looks quite dangerous and it's not portable to other platforms as it stands. Anything we implement should work on at least x86/x64 Windows and x86/x64/ARM Linux.
I had a closer look at "external debugger" api, doesn't seem to provide this functionality to queue a "TraceOn=1" trap out to the debugger at the next traceable code, which is great for pin pointing type checks (or async break key interruption). However the API is useful in this case to get the call stack when the non-traceable 'interruption' occurs, and then locate where the type check failed.
Well yes, it's an external debugger after all. But it does allow you set step through the code, set break points, and have access to the symbol table. So you could set up a debugger to indefinitely step through the code and checking for key events, and when it gets triggered, grab the call stack and symbol table and go inject the "trace on" op use Euphoria code instead of assembly. This is all hypothetical but I think there's enough implemented to make this possible.
Would break key 'interruption' in win32's seperate thread have a valid Euphoria call stack context, or is the thread anonymous without a Euphoria call context? In this case, is it even safe to run euphoria code (it seems to work) in the break handler thread, since I thought Euphoria is not multi-threaded, but one assumes that Euphoria callbacks are 'thread safe' even when they occur part way through a Euphoria byte code instruction.
From what I can tell, external callbacks drop into their own call stack and execution resumes normally after the callback returns. Everything's still in one thread, but as it stands the interpreter has no idea where it left off before the callback was triggered. But, there's already code built into the backend to handle check_break() so we might be able to utilize that to insert a "trace on" op as necessary.
I plan to look more at the debugging features later, but right now my priorities are memstruct and a handful of standard library features like hashes and compression.
-Greg
