From: Neil Jerram <neil@ossau.uklinux.net>
To: Guile Development <guile-devel@gnu.org>
Subject: Re: racing srfi-18 threads
Date: Thu, 03 Dec 2009 22:52:44 +0000 [thread overview]
Message-ID: <878wdjpt4z.fsf@ossau.uklinux.net> (raw)
In-Reply-To: <87ws1582wk.fsf@ossau.uklinux.net> (Neil Jerram's message of "Wed, 02 Dec 2009 21:46:51 +0000")
Neil Jerram <neil@ossau.uklinux.net> writes:
> [...] wondering whether and how we
> will provide similar debugging facilities for compiled code as we have
> in 1.8.x for interpreted code.
Some more thoughts here, to try to build a complete new picture.
Things that we can do quite nicely in 1.8.x are:
- stack inspection
- seeing the frames and what is happening, for context
- mapping back to source code
- querying variable values
- evaluating an expression in a frame's local environment
- breakpoints
- tracing
- single stepping.
We should try to include profiling and code coverage in the picture.
My thoughts for doing this in 2.0 are as follows.
- Single stepping, breakpoints, code coverage and tracing can all be
done by instrumenting code - either in Scheme, or with lower-level
language ops that somehow get inserted as code is compiled.
- The more I think about this, the more it seems clearly preferable to
the 1.8.x evaluator traps model - i.e. where there are ways of
_marking_ code in some way, and the evaluator or VM calls out to a
hook when it sees one of these marks. It's a simpler solution, and...
- It in particular removes the need for most of the complexity that we
have in 1.8.x's (ice-9 debugging traps). The complexity is mostly
about wanting to say 'do THIS when you start executing procedure FOO',
but the lowlevel traps interface not allowing us to specify either
'THIS' or 'when you start executing procedure FOO' precisely. (All we
can say is 'call a globally-defined function when you start executing
any of the currently marked procedures'.)
- I'm not clear how this interacts with optimisation... What
happens when an optimisation reorders or eliminates code with a
breakpoint? How do we present this to the user? It feels like a
soluble problem though.
- Instrumentation-based single-stepping would be more like edebug than
what we have in 1.8.x - i.e. the mode of operation would probably be
to instrument the whole of the body of a given function. But I think
that would be fine (and consistent for our plan for future emacs
domination :-)). (In contrast, 1.8.x single-stepping doesn't require
prior instrumentation, and allows stepping over function boundaries.)
- An unfortunate consequence of psyntax is backtraces being harder to
read, and to correlate back to source code, because of all the
alpha-renamed variables. When paused at a breakpoint, I think this
also makes it harder for the user to ask what the value of a given
variable is. Is there anything we can do about this - such as mapping
all the variable names back to their names in the original source
code?
- As one of Andy's eval commits says, we don't have local-eval any more
and so can't currently do "evaluate in a stack frame". I suppose the
most important case here is querying local variable values; is there a
reasonable solution for that?
Any thoughts on that?
> (SLIB has stuff like this too. I wonder if it would just work.)
(Currently blocked by SLIB not loading at all in 1.9/2.0:
scheme@(guile-user)> (use-modules (ice-9 slib))
;;; note: autocompilation is enabled, set GUILE_AUTO_COMPILE=0
;;; or pass the --no-autocompile argument to disable.
;;; compiling /usr/share/slib/guile.init
;;; WARNING: compilation of /usr/share/slib/guile.init failed:
;;; key syntax-error, throw args (sc-expand "~a in ~a" ("unexpected syntax" define) #f)
ERROR: In procedure sc-expand:
ERROR: unexpected syntax in define
)
Regards,
Neil
next prev parent reply other threads:[~2009-12-03 22:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2e6d10880911060129s538fab2cv84805475450f33d0@mail.gmail.com>
[not found] ` <2e6d10880911060652g56092de3g649c540e54102c05@mail.gmail.com>
[not found] ` <87bpjcy4bc.fsf@ossau.uklinux.net>
2009-11-16 22:16 ` racing srfi-18 threads Neil Jerram
2009-11-17 19:58 ` Andy Wingo
2009-11-20 0:00 ` Neil Jerram
2009-12-02 21:46 ` Neil Jerram
2009-12-03 22:52 ` Neil Jerram [this message]
2010-07-20 21:51 ` Andy Wingo
2009-12-10 19:53 ` Andy Wingo
2009-12-12 17:00 ` Debugging infrastructure (was Re: racing srfi-18 threads) Neil Jerram
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878wdjpt4z.fsf@ossau.uklinux.net \
--to=neil@ossau.uklinux.net \
--cc=guile-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).