[Top][All Lists]

[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:
> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]