Debugging infrastructure (was Re: racing srfi-18 threads)

[Neil Jerram <neil@ossau.uklinux.net>]

Andy Wingo <wingo@pobox.com> writes:

> Hi Neil,
>
> On Wed 02 Dec 2009 22:46, Neil Jerram <neil@ossau.uklinux.net> writes:
>
>> Neil Jerram <neil@ossau.uklinux.net> writes:
>>
>>> I now have it down to this: a program compiled inside the RHS of a
>>> define-syntax form apparently has no meta; whereas the same program
>>> compiled outside a define-syntax form does have meta:
>>
>> Apologies for taking so long to follow up on this!
>
> Dude, my apologies for not tracking mail... This particular bug was due
> to a bad check in compile-assembly.scm:make-meta. Fixed in
> 8986ff7ae9dcaae79d3ab262c360a6cbbc86c263.

Thanks!  I think I was on the right track, but still some way away from
this solution.

>> One option would be not to take the 1.8.x approach at all (i.e. using
>> special hooks from the core of the evaluator/VM) but instead rely on
>> instrumenting code at runtime.  I had a quick play with this and it
>> seems quite simple and promising.
>
> That is indeed useful, and robust.
>
> Some thoughts...
>
> 1. Something like your trace procedure does seem to be quite useful. 
>
> 2. At the same time, we should be able to trace any procedure at runtime
> without modifying it -- whether by using a different VM (possible) or by
> enabling hooks on the current VM.

Why?  Does this approach provide specific benefits, compared to
instrumentation?

> 3. When it comes time to have native compilation, things get trickier.
> Did you see today's LWN article on ftrace? It looks really really sweet.

Certainly the idea of having a ring buffer for tracing is good, instead
of outputting the trace directly.

Otherwise I think the main concept here is tracing function entry and
exit.

Mapped into Guile, my feeling/guess is that it is relatively unlikely
that we will need to support this at the C level of the VM.  The macro
that I posted adds instrumentation at the Scheme level, and I agree that
that is probably not optimal.  But we could also implement tracing by
inserting code in one of the compiler passes; that would be similar to
ftrace's use of -pg.  And we could arrange the inserted code to output
to a ring buffer, and so that its output was subject to current runtime
configuration.

>   http://lwn.net/SubscriberLink/365835/07f149ad48a74856/ -- and do
>   subscribe if you're not already, &c &c.

I am already.

> The compiler could easily instrument interesting pieces of code with
> NOPs, and a tracer could patch the code at runtime.
>
> Even more easy would be having the compiler produce actual calls to
> trace procedures at various points, for serious debugging.

Ah, sorry, I didn't read ahead before writing above!  So obviously I
agree.

> Also there are hardware breakpoints, but that's trickier.

So I'd suggest doing the immediately tractable stuff first, and seeing
if a need for hardware breakpoints arises.

>> We should be able to do breakpoints like this too, using either the
>> command line or the GDS debugger - although I'm not sure how much of the
>> stack inspection facilities will immediately work.  I'll try that
>> next.
>
> There is the break instruction.

Interesting.  But does anything currently generate that instruction?

> We have code for inspecting the local
> vars of a stack frame -- see program.scm and frame.scm.

Cool, thanks.

>> I don't see how single-stepping could easily be implemented this way,
>> though.  I think that may require hooks in the VM.  But then again,
>> would single stepping through VM operations be useful and comprehensible
>> anyway?
>
> Not usually no. But sometimes. More often expression-level stepping
> would be nice, or at least stepping function calls.

Agreed.  I wrote a bit more about this in my followup post.

Anyway, how should we proceed for playing with this area?  I should have
a little time over Christmas, and can use that to work on debugging and
the manual.  Do you want/plan to spend time on debugging too, or are you
happy just to discuss and provide input?

Regards,
        Neil