Andy Wingo <wi...@pobox.com> writes: > Hi Neil, > > On Wed 02 Dec 2009 22:46, Neil Jerram <n...@ossau.uklinux.net> writes: > >> Neil Jerram <n...@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
