From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6336 invoked by alias); 11 Nov 2013 01:50:11 -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 6310 invoked by uid 89); 11 Nov 2013 01:50:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=4.5 required=5.0 tests=AWL,BAYES_40,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RDNS_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: mail-we0-f180.google.com Received: from Unknown (HELO mail-we0-f180.google.com) (74.125.82.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 11 Nov 2013 01:50:09 +0000 Received: by mail-we0-f180.google.com with SMTP id q59so3938010wes.25 for ; Sun, 10 Nov 2013 17:50:00 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.189.80 with SMTP id gg16mr10317459wic.32.1384134600118; Sun, 10 Nov 2013 17:50:00 -0800 (PST) Received: by 10.194.37.73 with HTTP; Sun, 10 Nov 2013 17:50:00 -0800 (PST) In-Reply-To: <87k3gfpz7k.fsf@gnu.org> References: <87ob5vlr2s.fsf@gnu.org> <87k3gfpz7k.fsf@gnu.org> Date: Mon, 11 Nov 2013 06:28:00 -0000 Message-ID: Subject: Re: guile scripting for gdb From: Doug Evans To: =?ISO-8859-1?Q?Ludovic_Court=E8s?= Cc: Doug Evans , guile-user@gnu.org, gdb-patches@sourceware.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2013-11/txt/msg00269.txt.bz2 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 values >>> 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 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=92.