From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11472 invoked by alias); 17 Feb 2008 22:27:49 -0000 Received: (qmail 11464 invoked by uid 22791); 17 Feb 2008 22:27:49 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 17 Feb 2008 22:27:18 +0000 Received: from kahikatea.snap.net.nz (103.30.255.123.static.snap.net.nz [123.255.30.103]) by viper.snap.net.nz (Postfix) with ESMTP id 591413DA482; Mon, 18 Feb 2008 11:27:11 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id C06418FC6D; Mon, 18 Feb 2008 11:27:09 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18360.46269.11283.751538@kahikatea.snap.net.nz> Date: Sun, 17 Feb 2008 22:27:00 -0000 To: "Doug Evans" Cc: "Vladimir Prus" , gdb-patches@sources.redhat.com Subject: Re: [RFC] Variable objects for STL containers In-Reply-To: References: <18354.25849.317151.537741@kahikatea.snap.net.nz> <18360.38522.477967.328610@kahikatea.snap.net.nz> X-Mailer: VM 7.19 under Emacs 22.1.90.2 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/msg00281.txt.bz2 > 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? This is not any STL, but Gcc's STL. Gdb and Gcc are both part of the GNU project so should possibly have a special relationship. By unscaleable, I guess you mean not general. Hardwiring is a worry but I have briefly discussed this subject on the Gcc and been assured that the code used is quite stable. It's also a matter of keeping Gcc developers informed about intended use of Gcc internals. > If the knowledge was in a > collection of dlopen'd .so (or some such), and users could provide > more, then that might be reasonable. If you know how to do it, that would be an improvement. Presumably it could also be done at a later stage, adapting any hardwired solution. > [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.] I don't really understand how the python support will be implemented but I don't see why variable objects for STL containers should require Python libraries to be present. -- Nick http://www.inet.net.nz/~nickrob