From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1483 invoked by alias); 11 Nov 2013 11:48:04 -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 1471 invoked by uid 89); 11 Nov 2013 11:48:03 -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 11:48:01 +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 12:47:52 +0100 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) To: Doug Evans Cc: Doug Evans , guile-user@gnu.org, gdb-patches@sourceware.org Subject: Re: guile scripting for gdb References: <87ob5vlr2s.fsf@gnu.org> <87k3gfpz7k.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 11:55:00 -0000 In-Reply-To: (Doug Evans's message of "Sun, 10 Nov 2013 17:50:00 -0800") Message-ID: <871u2np3bs.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/msg00286.txt.bz2 Doug Evans skribis: > On Sun, Nov 10, 2013 at 4:19 PM, Ludovic Court=C3=A8s wrot= e: >> Doug Evans skribis: >> >>> On Thu, Nov 7, 2013 at 3:39 PM, Ludovic Court=C3=A8s wro= te: >> >> [...] >> >>>> 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 prog= rams, >> >> 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 b= y =E2=80=98lookup-type=E2=80=99 >> is the same as that returned by =E2=80=98arch-int-type=E2=80=99, yet the= SMOBs are >> different. >> >> Fixing it would require maintaining a C->SMOB mapping. > > I'm pretty sure we have a sufficiently similar idea in mind. > I mention the use of multiple tables because the lifetimes of > different kinds of objects are different, and it may be easier to > delete the table than iterate over each element looking for entries > that need to be deleted. > > For reference sake, gdb doesn't guarantee that in the above example > the underlying pointers are equal. > While the arch provides a definition of "int" it can also come from > the debug info in the program (actually there can and typically will > be several copies, one from each .o in the program). > eq-ness will be problematic even with the C->SMOB mapping. Ah, OK. Indeed, eq?-ness only would only matter in cases where gdb guarantees pointer equality in the first place. Thanks for the explanation, Ludo=E2=80=99.