From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Doug Evans Newsgroups: gmane.lisp.guile.user,gmane.comp.gdb.patches Subject: Re: guile scripting for gdb Date: Sat, 9 Nov 2013 10:40:18 -0800 Message-ID: References: <87ob5vlr2s.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1384022447 10051 80.91.229.3 (9 Nov 2013 18:40:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Nov 2013 18:40:47 +0000 (UTC) Cc: guile-user@gnu.org, gdb-patches@sourceware.org To: =?ISO-8859-1?Q?Ludovic_Court=E8s?= Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sat Nov 09 19:40:52 2013 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VfDSj-0004hY-2P for guile-user@m.gmane.org; Sat, 09 Nov 2013 19:40:49 +0100 Original-Received: from localhost ([::1]:58019 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VfDSi-0002UR-I3 for guile-user@m.gmane.org; Sat, 09 Nov 2013 13:40:48 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50863) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VfDSK-0002NO-91 for guile-user@gnu.org; Sat, 09 Nov 2013 13:40:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VfDSG-0005Si-8m for guile-user@gnu.org; Sat, 09 Nov 2013 13:40:24 -0500 Original-Received: from mail-wg0-f42.google.com ([74.125.82.42]:45436) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VfDSG-0005SU-2R for guile-user@gnu.org; Sat, 09 Nov 2013 13:40:20 -0500 Original-Received: by mail-wg0-f42.google.com with SMTP id k14so870668wgh.5 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=JN75RSebiOLdBq5MVmJ4cqh7Q5/FlmuOePbo5BSC2r19IqqVv6u3tYYWGypncvV1UW aChOsm736bpOfFzRaJWcct1Lk2LUaBhnt4eU99JxHjNogUmZQHt+74dPUCv/0CVyg053 lV9l951KfcFEoliT9d2JANGUeoWKeJTvCpUHJNVcJ4zG2vwHRerBzemP6FblkshTLf/U CR0WeymPY8eM2eIXn+jH23jIO0ba+ZXhaE0WA2SoJjrSQaIEXl3nDuAqmj6xrV+hN/iM CZwvJR07V4OQZZykeluV7gsx7zcbiu0ST9dwRn4IzcvxQ0ReCR3Ezywqz7ExnDyKmZ56 uiLA== X-Gm-Message-State: ALoCoQkGJM8nFY78vEFIXk1z2krytw60Vp+pUgVCLxm2K3xNhZKxdVOPBvk7iGS6Axe3dBv8I+OF X-Received: by 10.181.11.163 with SMTP id ej3mr6520355wid.47.1384022418339; Sat, 09 Nov 2013 10:40:18 -0800 (PST) Original-Received: by 10.216.73.198 with HTTP; Sat, 9 Nov 2013 10:40:18 -0800 (PST) In-Reply-To: <87ob5vlr2s.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 74.125.82.42 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:10874 gmane.comp.gdb.patches:92093 Archived-At: 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.