From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19531 invoked by alias); 17 Feb 2008 21:57:55 -0000 Received: (qmail 19522 invoked by uid 22791); 17 Feb 2008 21:57:55 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 17 Feb 2008 21:57:37 +0000 Received: from zps76.corp.google.com (zps76.corp.google.com [172.25.146.76]) by smtp-out.google.com with ESMTP id m1HLvPlZ015429 for ; Sun, 17 Feb 2008 21:57:28 GMT Received: from wa-out-1112.google.com (wahk40.prod.google.com [10.114.237.40]) by zps76.corp.google.com with ESMTP id m1HLvOxC006040 for ; Sun, 17 Feb 2008 13:57:25 -0800 Received: by wa-out-1112.google.com with SMTP id k40so3188645wah.25 for ; Sun, 17 Feb 2008 13:57:24 -0800 (PST) Received: by 10.114.107.19 with SMTP id f19mr4127248wac.113.1203285444773; Sun, 17 Feb 2008 13:57:24 -0800 (PST) Received: by 10.115.107.7 with HTTP; Sun, 17 Feb 2008 13:57:24 -0800 (PST) Message-ID: Date: Sun, 17 Feb 2008 21:57:00 -0000 From: "Doug Evans" To: "Nick Roberts" Subject: Re: [RFC] Variable objects for STL containers Cc: "Vladimir Prus" , gdb-patches@sources.redhat.com In-Reply-To: <18360.38522.477967.328610@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <18354.25849.317151.537741@kahikatea.snap.net.nz> <18360.38522.477967.328610@kahikatea.snap.net.nz> X-IsSubscribed: yes 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 X-SW-Source: 2008-02/txt/msg00280.txt.bz2 On Feb 17, 2008 12:18 PM, Nick Roberts wrote: > > I think for lists, maps etc, Gdb needs to traverse the internal data structure > each to see if there are new elements or if any have been deleted. This need > only be done when execution stops, of course, but I guess it could be expensive > for stepping. > > The ideas here are just for discussion and I'm more than happy to look at any > changes you might like to make. There's something I don't understand, and maybe you can help clear things up. It seems like this approach is going down a path of hardwiring a lot of knowledge into gdb. Solving this just for STL (and then only one version of STL) seems to be one piece of a general problem, why pick an unscalable solution? If the knowledge was in a collection of dlopen'd .so (or some such), and users could provide more, then that might be reasonable. [Setting aside use of python for this, I understand there is some pushback to going that route. It'd be cool if the python support used the same interface, then one could have it both ways. The python support is, of course, not just for this and one wouldn't want python to plug into gdb in a piecemeal fashion. OTOH, if a clean solution could be found that let one solve this with either C[/C++] or python then that might be very useful.]