Re: tracepoints/breakpoints and native compilation

[Andy Wingo <wingo@pobox.com>]

On Tue 15 May 2018 05:08, Mark H Weaver <mhw@netris.org> writes:

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

Tx for feedback.  FWIW GDB will patch the executable code in-place.  It
does so while the program being debugged is stopped; it uses ptrace for
this AFAIU.  I guess in Guile we'd set asyncs on all active threads to
synchronize.  Actually modifying the executable code is pretty gnarly
and target-specific though.

FWIW JS and Java VMs will often "deoptimize" functions that have
breakpoints or tracepoints.  Some can avoid deoptimization in some
cases, but the mechanism is the same: recompile functions.

The hooks that Guile has aren't so legacy, and aren't immutable API --
they showed up in 2.0, changed a bit in 2.2, and if we keep them they
will change a bit more in 3.0.  Their users are already deep in the
engine and can adapt.

Regarding GDB, it would certainly be feasible to enhance it to
understand Guile's native code.  Probably it's all possible to do from
Scheme.  But for tracepoints and and for when you don't have an
appropriate GDB you probably do want to be able to also have in-process
debugging capabilities.

Cheers,

Andy