Debugging infrastructure (was Re: racing srfi-18 threads)
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
Re: r6rs libraries, round three
Hi all,
Find attached updated versions of the patches that provide support for
R6RS-compatible versions and renaming bindings on export (the two core
modifications required to support the libraries implementation).
They've been rebased against the current HEAD and some reasonably
comprehensive documentation has been added.
Questions? Comments?
Regards,
Julian
From bb83bbd13263aca6a1e8b246fd68ce96f5dcdb43 Mon Sep 17 00:00:00 2001
From: Julian Graham julian.gra...@aya.yale.edu
Date: Thu, 10 Dec 2009 00:29:11 -0500
Subject: [PATCH 1/2] Support for renaming bindings on module export.
* module/ice-9/boot-9.scm (module-export!, module-replace!, module-re-export!):
Allow members of export list to be pairs, mapping internal names to external ones.
* doc/ref/api-modules.texi (Creating Guile Modules): Update documentation for `#:export', `#:export-syntax', `#:replace', `#:re-export', `#:re-export-syntax', `export', and `re-export' to reflect new format for arguments.
---
doc/ref/api-modules.texi | 50 +
module/ice-9/boot-9.scm | 24 +
2 files changed, 43 insertions(+), 31 deletions(-)
diff --git a/doc/ref/api-modules.texi b/doc/ref/api-modules.texi
index 1c9ab23..65a3564 100644
--- a/doc/ref/api-modules.texi
+++ b/doc/ref/api-modules.texi
@@ -421,40 +421,42 @@ the module is used.
@item #:export @var{list}
@cindex export
-Export all identifiers in @var{list} which must be a list of symbols.
-This is equivalent to @code{(export @var{list})} in the module body.
+Export all identifiers in @var{list} which must be a list of symbols
+or pairs of symbols. This is equivalent to @code{(export @var{list})}
+in the module body.
@item #:re-export @var{list}
@cindex re-export
Re-export all identifiers in @var{list} which must be a list of
-symbols. The symbols in @var{list} must be imported by the current
-module from other modules. This is equivalent to @code{re-export}
-below.
+symbols or pairs of symbols. The symbols in @var{list} must be
+imported by the current module from other modules. This is equivalent
+to @code{re-export} below.
@item #:export-syntax @var{list}
@cindex export-syntax
-Export all identifiers in @var{list} which must be a list of symbols.
-The identifiers in @var{list} must refer to macros (@pxref{Macros})
-defined in the current module. This is equivalent to
-...@code{(export-syntax @var{list})} in the module body.
+Export all identifiers in @var{list} which must be a list of symbols
+or pairs of symbols. The identifiers in @var{list} must refer to
+macros (@pxref{Macros}) defined in the current module. This is
+equivalent to @code{(export-syntax @var{list})} in the module body.
@item #:re-export-syntax @var{list}
@cindex re-export-syntax
Re-export all identifiers in @var{list} which must be a list of
-symbols. The symbols in @var{list} must refer to macros imported by
-the current module from other modules. This is equivalent to
-...@code{(re-export-syntax @var{list})} in the module body.
+symbols or pairs of symbols. The symbols in @var{list} must refer to
+macros imported by the current module from other modules. This is
+equivalent to @code{(re-export-syntax @var{list})} in the module body.
@item #:replace @var{list}
@cindex replace
@cindex replacing binding
@cindex overriding binding
@cindex duplicate binding
-Export all identifiers in @var{list} (a list of symbols) and mark them
-as @dfn{replacing bindings}. In the module user's name space, this
-will have the effect of replacing any binding with the same name that
-is not also ``replacing''. Normally a replacement results in an
-``override'' warning message, @code{#:replace} avoids that.
+Export all identifiers in @var{list} (a list of symbols or pairs of
+symbols) and mark them as @dfn{replacing bindings}. In the module
+user's name space, this will have the effect of replacing any binding
+with the same name that is not also ``replacing''. Normally a
+replacement results in an ``override'' warning message,
+...@code{#:replace} avoids that.
This is useful for modules that export bindings that have the same
name as core bindings. @code{#:replace}, in a sense, lets Guile know
@@ -562,8 +564,11 @@ do not know anything about dangerous procedures.
@c end
@deffn syntax export variable @dots{}
-Add all @var{variable}s (which must be symbols) to the list of exported
-bindings of the current module.
+Add all @var{variable}s (which must be symbols or pairs of symbols) to
+the list of exported bindings of the current module. If @var{variable}
+is a pair, its @code{car} gives the name of the variable as seen by the
+current module and its @code{cdr} specifies a name for the binding in
+the current module's public interface.
@end deffn
@c begin (scm-doc-string boot-9.scm define-public)
@@ -573,9 +578,10 @@ Equivalent to @code{(begin (define foo ...) (export foo))}.
@c end
@deffn syntax re-export variable @dots{}
