Re: tracepoints/breakpoints and native compilation

[Mark H Weaver]

Hi Andy,

Andy Wingo <address@hidden> 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