From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.devel,gmane.lisp.guile.user Subject: Debugging infrastructure (was Re: racing srfi-18 threads) Date: Sat, 12 Dec 2009 17:00:17 +0000 Message-ID: <87d42kktzy.fsf_-_@ossau.uklinux.net> References: <2e6d10880911060129s538fab2cv84805475450f33d0@mail.gmail.com> <2e6d10880911060652g56092de3g649c540e54102c05@mail.gmail.com> <87bpjcy4bc.fsf@ossau.uklinux.net> <87skceglog.fsf@ossau.uklinux.net> <87my2iuksq.fsf@ossau.uklinux.net> <87ws1582wk.fsf@ossau.uklinux.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1260637645 1892 80.91.229.12 (12 Dec 2009 17:07:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 12 Dec 2009 17:07:25 +0000 (UTC) Cc: guile-user@gnu.org, Guile Development To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Dec 12 18:07:18 2009 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NJVR1-000102-Lt for guile-devel@m.gmane.org; Sat, 12 Dec 2009 18:07:11 +0100 Original-Received: from localhost ([127.0.0.1]:54454 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NJVR1-0006sp-Er for guile-devel@m.gmane.org; Sat, 12 Dec 2009 12:07:11 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NJVLC-0003FY-Rk for guile-devel@gnu.org; Sat, 12 Dec 2009 12:01:10 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NJVL8-0003E4-Jv for guile-devel@gnu.org; Sat, 12 Dec 2009 12:01:10 -0500 Original-Received: from [199.232.76.173] (port=58924 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NJVL2-0003Dm-1V; Sat, 12 Dec 2009 12:01:00 -0500 Original-Received: from mail3.uklinux.net ([80.84.72.33]:37964) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NJVL1-0006ir-8R; Sat, 12 Dec 2009 12:00:59 -0500 Original-Received: from arudy (host81-153-58-148.range81-153.btcentralplus.com [81.153.58.148]) by mail3.uklinux.net (Postfix) with ESMTP id 0EE2A1F668A; Sat, 12 Dec 2009 17:00:22 +0000 (GMT) Original-Received: from arudy (arudy [127.0.0.1]) by arudy (Postfix) with ESMTP id 1BA8338023; Sat, 12 Dec 2009 17:00:18 +0000 (GMT) In-Reply-To: (Andy Wingo's message of "Thu, 10 Dec 2009 20:53:10 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:9762 gmane.lisp.guile.user:7534 Archived-At: Andy Wingo writes: > Hi Neil, > > On Wed 02 Dec 2009 22:46, Neil Jerram writes: > >> Neil Jerram 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