Hi Andy, Andy Wingo <wi...@pobox.com> writes:
> A design question for everyone. I am wondering how to support > breakpoints, tracepoints, and the like in a Guile with native-code > compilation. If you are not familiar with what Guile does currently, > see: > > https://www.gnu.org/software/guile/manual/html_node/Traps.html > > Basically Guile supports calling out to user-defined procedures when: > > (1) pushing a new continuation (stack frame) > (2) tail-calling a procedure > (3) popping a continuation (e.g. on return) > (4) non-local return (after abort, or after calling a call/cc continuation) > (5) advancing the instruction pointer I think we should consider deprecating these legacy debug hooks, and instead to support debugging features similar to GDB, using the same implementation methods that GDB uses. Alternatively, I wonder if it would be feasible to enhance GDB itself to support debugging native Guile code. > However if we ship native code in the .go files -- what do we do? Three > options, I see -- one, ship "regular" code (no hooks) -- fast, but no > breakpoints from Guile. Two, ship "debug" code (with hooks). Or three, > ship the bytecode also, and a JIT compiler, so that we can re-JIT if > needed. If we keep the hooks, then I agree that option three is best. Thanks! Mark
