On Tue 15 May 2018 05:08, Mark H Weaver <m...@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
