From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27371 invoked by alias); 11 Nov 2013 00:19:24 -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 27357 invoked by uid 89); 11 Nov 2013 00:19:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_50,RDNS_NONE,SPF_SOFTFAIL,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: mail3-relais-sop.national.inria.fr Received: from Unknown (HELO mail3-relais-sop.national.inria.fr) (192.134.164.104) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Mon, 11 Nov 2013 00:19:22 +0000 Received: from reverse-83.fdn.fr (HELO pluto) ([80.67.176.83]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 11 Nov 2013 01:19:12 +0100 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) To: Doug Evans Cc: guile-user@gnu.org, gdb-patches@sourceware.org Subject: Re: guile scripting for gdb References: <87ob5vlr2s.fsf@gnu.org> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 21 Brumaire an 222 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 83C4 F8E5 10A3 3B4C 5BEA D15D 77DD 95E2 EA52 ECF4 X-OS: x86_64-unknown-linux-gnu Date: Mon, 11 Nov 2013 01:50:00 -0000 In-Reply-To: (Doug Evans's message of "Sat, 9 Nov 2013 10:40:18 -0800") Message-ID: <87k3gfpz7k.fsf@gnu.org> User-Agent: Gnus/5.130007 (Ma Gnus v0.7) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2013-11/txt/msg00268.txt.bz2 Doug Evans skribis: > On Thu, Nov 7, 2013 at 3:39 PM, Ludovic Court=C3=A8s wrote: [...] >> 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 progra= ms, What I had in mind was something simpler: suppose you have the very same C struct pointer reaches the Scheme level, at two different points in time, or via two different paths; currently gdb may end up allocating two different SMOBs (i.e., two SMOBs that are not eq?), whereas I would suggest making sure there=E2=80=99s only one SMOB. Example: --8<---------------cut here---------------start------------->8--- (gdb) guile (lookup-type "int") # (gdb) guile (arch-int-type (current-arch)) # (gdb) guile (eq? (lookup-type "int") (arch-int-type (current-arch))) #f --8<---------------cut here---------------end--------------->8--- Here I bet the underlying =E2=80=98struct type=E2=80=99 pointer return by = =E2=80=98lookup-type=E2=80=99 is the same as that returned by =E2=80=98arch-int-type=E2=80=99, yet the SM= OBs are different. Fixing it would require maintaining a C->SMOB mapping. > if we want eq?-ness to survive across the lifetime of the underlying gdb = object > 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? Yes, a lot can already be done with the current semantics, but at some point it may break the user=E2=80=99s expectations. It=E2=80=99s natural t= o compare presumably-pointer-identical objects with eq?, or to use eq? hash tables. [...] >> An interesting exercise would be to write pretty-printers for SCM values >> and tools to walk Guile=E2=80=99s VM stack (like Guile=E2=80=99s gdbinit= attempts to do). > > Agreed, excellent exercises. > > gdb has a "frame filter" interface that's intended to be used to > implement multi-language backtraces. That sounds cool. If gdb could show trace mixing both stacks, that=E2=80= =99d be nice. > 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. Yeah, the VM in 2.2 is completely different. Thanks, Ludo=E2=80=99.