Re: racing srfi-18 threads

[Andy Wingo <wingo@pobox.com>]

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.

> I've been trying to remedy my lack of detailed understanding about how
> compilation works, and that has led me to wondering whether and how we
> will provide similar debugging facilities for compiled code as we have
> in 1.8.x for interpreted code.

I would hope so! 

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

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.

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

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.

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

Dunno, my thoughts here are scattered.

> Yes, I know I should write that with define-syntax instead. :-)

Probably yes :)

> 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. We have code for inspecting the local
vars of a stack frame -- see program.scm and frame.scm.

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

Cheers,

Andy
-- 
http://wingolog.org/