Re: Guile debugger workgroup?

[Attila Lendvai <attila@lendvai.name>]

> > > The scenario you describe above should be possible above (there is a
> > > debugger that supports breakpoints and single stepping). Now, it may
> > > be, as you wrote, that inlining can lead breakpoints to never be hit, or
> > > that there are bugs in this area. These things should be fixed, I agree.
> > 
> > i'm sure there's a way to globally override the debug/optimization/inlining level in guile to make sure the code compiles in a way that no breakpoints are missed (and/or backtraces remain more intact, etc).
> 
> 
> Note that I’m not even sure this bug exists (hence “may” :-)) but if it
> does, you’re right, it’s probably a matter of compiling with -O1.


i would be quite surprised if brakepoints in Guile worked on inlined function invocations... but hey! i like positive surprises! :)

but in general, optimized code is usually less debuggable due to the tradeoffs taken. having a means to force parts of the codebase to run in unoptimized form is usually very helpful when debugging.

and sometimes it makes sense to straight out force parts of the code to always be unoptimized, or run in the interpreter, if it's not in a hotspot of the codebase, and it's expected to be involved often in situations where errors are raised.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Liberty means responsibility. That is why most men dread it.”
	— George Bernard Shaw (1856–1950), 'Man and Superman'