From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7564 invoked by alias); 28 Feb 2003 20:58:28 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 7542 invoked from network); 28 Feb 2003 20:58:27 -0000 Received: from unknown (HELO mail-out2.apple.com) (17.254.0.51) by 172.16.49.205 with SMTP; 28 Feb 2003 20:58:27 -0000 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.12.3/8.12.3) with ESMTP id h1SKwRTb020301 for ; Fri, 28 Feb 2003 12:58:27 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 28 Feb 2003 12:58:26 -0800 Received: from apple.com (moleja.apple.com [17.201.22.21]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id h1SKwQf26333; Fri, 28 Feb 2003 12:58:26 -0800 (PST) Date: Fri, 28 Feb 2003 20:58:00 -0000 Subject: Re: [rfc] xfailed tests in gdb.c++/classes.exp Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: carlton@math.stanford.edu, drow@mvista.com, gdb@sources.redhat.com To: Michael Elizabeth Chastain From: Jason Molenda In-Reply-To: <200302280351.h1S3p6525237@duracef.shout.net> Message-Id: <2CD1C12F-4B5F-11D7-B016-003065BC3540@apple.com> Content-Transfer-Encoding: 7bit X-SW-Source: 2003-02/txt/msg00611.txt.bz2 I like to pull mail threads utterly off-topic whenever possible: On Thursday, February 27, 2003, at 07:51 PM, Michael Elizabeth Chastain wrote: > If you look in gnats, you will see users complaining that they can't > print their string variables (because C++ strings are implemented with > layers of templates and derived classes). They are complaining that > operator overloading doesn't work. They are complaining that they have > a std::vector and they can't even look inside the damn thing. We have the same problem here at Apple, introspecting objects. As a convention, many of the standard Cocoa Objective C classes include a "NSPrintForDebugger" member function which can print the object in some way that is meaningful to the developer. We have a gdb command, "print-object" or "po" which does an inferior function call into this. In the GUI, we let users right-click on locals et al and do this command. It's not fancy/seamless/beautiful, but it is enough for users to do what they need. It does depend on support from the class libraries, obviously. That's still not ideal - your Locals window still shows a bunch of variables with raw pointers instead of the strings they contain. Rab Hagy added a feature last summer to display these objects as strings when using the ProjectBuilder GUI. He added a solib that is loaded into the inferior to provide some object introspection functions in the inferior executable, and at a stop he determines if an object is an NSString class or inherited from that class, and then gets the formatted version of that text. This approach is very expensive (making an inferior function call for each local object for each step) so we'll surely need to refine it in the future, but it's a step in the right direction. Well, Rab could provide better details on what he did and where he sees this going (I was utterly uninvolved), but we're looking at these same problems here at Apple. We haven't cracked into the C++ library yet, but the problems are of a similar sort. J