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: Sun, 10 Nov 2013 17:50:00 -0800 Message-ID: References: <87ob5vlr2s.fsf@gnu.org> <87k3gfpz7k.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 1384134610 6418 80.91.229.3 (11 Nov 2013 01:50:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 11 Nov 2013 01:50:10 +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 Mon Nov 11 02:50:13 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 1Vfgdo-0002eK-GE for guile-user@m.gmane.org; Mon, 11 Nov 2013 02:50:12 +0100 Original-Received: from localhost ([::1]:34319 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vfgdn-0003gv-WF for guile-user@m.gmane.org; Sun, 10 Nov 2013 20:50:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51066) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vfgdf-0003fb-Gv for guile-user@gnu.org; Sun, 10 Nov 2013 20:50:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vfgdd-0003sN-TP for guile-user@gnu.org; Sun, 10 Nov 2013 20:50:03 -0500 Original-Received: from mail-wi0-x231.google.com ([2a00:1450:400c:c05::231]:37975) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vfgdd-0003s2-MO; Sun, 10 Nov 2013 20:50:01 -0500 Original-Received: by mail-wi0-f177.google.com with SMTP id hq4so1128318wib.4 for ; Sun, 10 Nov 2013 17:50:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=xwY8Bu28DVhoK8bUDICG6geqASc3jQ0jIRMJMDdjFHk=; b=Q/gIkINDZG12eO5kyIe21+9Mcl4fwK9akpbTc1U2WvecdLswf2hU041qySuns9RuYm FSFBxZp0hry6eciMxo27mfGZpxdbNtsRzLXGizx1kuP4sPywtuXA86TSuiH4sBfxV6X6 DI2eHMHqQfjOlgqEF5t8v9br9JYPc+w2yIxmIaUSf/l5jvbkymXThu/cWKQvhYx9EwFq 0O61FH5EAG7EUJUXPu9XpYbOuPD2KBnweqrOXcOVpo/mI8rOyQbASZgPSQi/aAQILe1o 0PD5WPAv/lj12tW7AyVS6NP5R61Q7YhXtkO3tcIHwzbZMd4y444FiAB27MH4KgvDAWEY srzg== X-Received: by 10.180.189.80 with SMTP id gg16mr10317459wic.32.1384134600118; Sun, 10 Nov 2013 17:50:00 -0800 (PST) Original-Received: by 10.194.37.73 with HTTP; Sun, 10 Nov 2013 17:50:00 -0800 (PST) In-Reply-To: <87k3gfpz7k.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::231 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:10883 gmane.comp.gdb.patches:92105 Archived-At: On Sun, Nov 10, 2013 at 4:19 PM, Ludovic Court=E8s wrote: > Doug Evans skribis: > >> On Thu, Nov 7, 2013 at 3:39 PM, Ludovic Court=E8s 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 progr= ams, > > 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=92s 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 =91struct type=92 pointer return by =91lookup-t= ype=92 > is the same as that returned by =91arch-int-type=92, 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. >> 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=92s expectations. It=92s natural to compare > presumably-pointer-identical objects with eq?, or to use eq? hash > tables. No disagreement there. > [...] > >>> An interesting exercise would be to write pretty-printers for SCM value= s >>> and tools to walk Guile=92s VM stack (like Guile=92s gdbinit attempts t= o 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=92d b= e > 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=92.