From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13053 invoked by alias); 16 Jan 2003 18:53:05 -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 13006 invoked from network); 16 Jan 2003 18:53:03 -0000 Received: from unknown (HELO mail-out2.apple.com) (17.254.0.51) by sources.redhat.com with SMTP; 16 Jan 2003 18:53:03 -0000 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id h0GIr3I06409 for ; Thu, 16 Jan 2003 10:53:03 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 16 Jan 2003 10:53:03 -0800 Received: from apple.com (inghji.apple.com [17.201.22.240]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id h0GIr2Q09635 for ; Thu, 16 Jan 2003 10:53:02 -0800 (PST) Date: Thu, 16 Jan 2003 18:53:00 -0000 Subject: Re: casting in gdb Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Jim Ingham To: gdb@sources.redhat.com Content-Transfer-Encoding: 7bit In-Reply-To: <1042721692.8268.ezmlm@sources.redhat.com> Message-Id: X-SW-Source: 2003-01/txt/msg00295.txt.bz2 David, For ObjC, where getting to the real data of an object is sometimes highly non-trivial, we used method calls in the inferior. We insert a shared library into the inferior process when we launch it. This shared library has functions that produce a user-friendly view of the object passed to them and stuff it somewhere in inferior memory. Then a client (PB in our case) can read out this memory and show that to the user. However, for STL classes the job is a little easier, since you can mostly get what you want from presenting various members of the class (or one of its sub-classes), perhaps with appropriate casts. For this case, we were planning to do something more like what Visual Studio or CodeWarrior do. Both of these allow users to associate some custom printing description with a given type. CW & VS use an XML description file giving what members to print - and what cast operation to apply to the members - for a given C++ type. This is faster than the ObjC method, since it does not involve inferior function calls, so where it is possible to use something like this it is preferable. We haven't gotten past the investigation of what CW & VC++ do, and I am not sure yet whether we will implement this in gdb, or let PB drive. So what we end up doing may or may not be interesting to the gdb community. PB already has an XML parser, and the facilities to manage this sort of thing, so it is more natural for us to do it there. Jim On Thursday, January 16, 2003, at 04:54 AM, gdb-digest-help@sources.redhat.com wrote: > On Sat, 14 Dec 2002 23:47:42 -0600, Michael Elizabeth Chastain > said: > >> I'm playing with the idea that gdb should know more about the C++ >> standard library types, in the same spirit that gdb knows that a C >> "char *" usually points to a string terminated with '\0'. I would >> like gdb to understood more about std::string, std::vector, std:map, >> and so on. > > I was going through my old messages, and I noticed this one. For what > it's worth, Apple has implemented something like this for strings in > Objective C, where they actually print out the string in question, and > they say it works pretty well. Apparently the implementation of > strings is complicated enough that they really didn't want to tie it > to the implementation; so GDB prints out Objective C strings by > actually doing the method call. > > Of course, the above message was part of a thread that noted that, in > C++, the appropriate methods might not be compiled in. That's a real > problem; I'm not sure what to do about that. > > David Carlton > carlton@math.stanford.edu > -- Jim Ingham jingham@apple.com Developer Tools Apple Computer