[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: tracepoints/breakpoints and native compilation
From: |
Mark H Weaver |
Subject: |
Re: tracepoints/breakpoints and native compilation |
Date: |
Mon, 14 May 2018 23:08:16 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) |
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