From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31276 invoked by alias); 9 Nov 2013 18:41:32 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 28824 invoked by uid 89); 9 Nov 2013 18:40:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: mail-we0-f182.google.com Received: from Unknown (HELO mail-we0-f182.google.com) (74.125.82.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sat, 09 Nov 2013 18:40:27 +0000 Received: by mail-we0-f182.google.com with SMTP id u56so614327wes.27 for ; Sat, 09 Nov 2013 10:40:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XSpY6qANu+nCAt15Gw/AA+tN5KlT5fFwsLhXkd0/nRA=; b=dDCMPw7S0opEfQNqYMWm4Do9L6sV6xBIoU4obaGO89TmJeBV2vJumGZ8X1XbOSxkWP 2rPryuorVMCGNxhpCHEXNUjgYCs2SbXiAN/9KVbFrH5+kShfEwmgIggRhN9rx6qNpbRh ZcoJrcEIgUa8jA7ktDLGmqjHGtGoxCRZM3UL1PfrAyF/fAZrEuWlBSrSwlrPKmWuQmqo 2tpNdzH/+jXzV5prYUELUxMMa/3TieYGMNTntN5VgNAiYpn3+8BvKZzYVkVDXEplucHM mbhTuiOOSmZmjCkpwVFvQIhJsxxwCAaQgWa//n3Sv7xRfIeD/hTxx45VYQQ93m+mGHLE vBAA== X-Gm-Message-State: ALoCoQlYtSehP+YgnBwwxZSJoBIgW/H6TURPEHk79MXUmzawNt7BgV11GGg4GZ7k9xFup5HuuhJa MIME-Version: 1.0 X-Received: by 10.181.11.163 with SMTP id ej3mr6520355wid.47.1384022418339; Sat, 09 Nov 2013 10:40:18 -0800 (PST) Received: by 10.216.73.198 with HTTP; Sat, 9 Nov 2013 10:40:18 -0800 (PST) In-Reply-To: <87ob5vlr2s.fsf@gnu.org> References: <87ob5vlr2s.fsf@gnu.org> Date: Sat, 09 Nov 2013 19:47:00 -0000 Message-ID: Subject: Re: guile scripting for gdb From: Doug Evans To: =?ISO-8859-1?Q?Ludovic_Court=E8s?= Cc: guile-user@gnu.org, gdb-patches@sourceware.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2013-11/txt/msg00257.txt.bz2 On Thu, Nov 7, 2013 at 3:39 PM, Ludovic Court=E8s wrote: > Hello, > > Doug Evans skribis: > >> fyi, I've uploaded my gdb-guile branch to github. >> >> https://github.com/dje42/gdb.git >> >> It's in branch gdb-guile. > > Nice piece of work from several angles (implementation strategy, test > coverage, style, docstrings, comments, etc.) To be fair, a lot of it derives from the Python version (gdb/python/*.[ch]). >> It's still very preliminary, there's still lots to do, and there are >> some open issues. > > As discussed on IRC, one possible issue is eq?-ness of SMOBs: one would > usually expects pointer equality to be preserved at the Scheme level. Yeah. That'll require gdb maintaining its own table(s) for each kind of smob we want to intern. Definitely doable, though there are some issues. E.g., while std::vector may be the same type in two different programs, if we want eq?-ness to survive across the lifetime of the underlying gdb ob= ject then that would take extra effort to make that work. Would it be ok to punt on eq?-ness until there's a compelling reason to make it work? At that point we'd have a better idea of the use-case involved, and data on the speed improvement eq? would bring to the table in that instance. And even then we might still have eq?-ness defined by the lifetime of the underlying gdb object (until there's a compelling reason to then make that work). > Another question I had is the lifetime of Scheme objects vs. that of the > underlying C objects. AIUI C objects cannot be forcefully kept alive > when their Scheme representative is live, which is why the bindings have > this notion of =93invalid=94 object at the Scheme level. Is it also the = way > the Python bindings deal with the issue? > > Random remarks: > > =95 The disasm interface looks cool. I think it=92d be more convenient= if > it used records to represent disassembled instructions. Thanks. I wanted to make it general so that we could disassemble more than just code from the program. I wasn't sure which things to make as records or goops objects or ... So I'm starting small. Each disassembly is just immutable data so it's easy enough to write wrappers to provide the API one wants. > =95 It would be nice to wrap the iterator interface in SRFI-41 streams. Yeah, I have a TODO to look into that. > An interesting exercise would be to write pretty-printers for SCM values > and tools to walk Guile=92s VM stack (like Guile=92s gdbinit attempts to = do). Agreed, excellent exercises. gdb has a "frame filter" interface that's intended to be used to implement multi-language backtraces. Need to add a gdb/guile interface. I'm not sure how Guile's new VM changes things - someone may want to write one for 2.0 and one for 2.2.