From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25774 invoked by alias); 15 Jul 2004 19:38: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 25760 invoked from network); 15 Jul 2004 19:38:04 -0000 Received: from unknown (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org with SMTP; 15 Jul 2004 19:38:04 -0000 Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i6FJcOhj025850 for ; Thu, 15 Jul 2004 12:38:24 -0700 (PDT) Received: from relay1.apple.com (relay1.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id ; Thu, 15 Jul 2004 12:38:04 -0700 Received: from [17.201.22.21] (moleja.apple.com [17.201.22.21]) by relay1.apple.com (8.12.11/8.12.11) with ESMTP id i6FJc2Iu000841; Thu, 15 Jul 2004 12:38:02 -0700 (PDT) In-Reply-To: <27560.62.255.64.4.1089918318.squirrel@webmail.euv-frankfurt-o.de> References: <27560.62.255.64.4.1089918318.squirrel@webmail.euv-frankfurt-o.de> Mime-Version: 1.0 (Apple Message framework v669) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7B90E592-D696-11D8-BBF3-000A9569836A@apple.com> Cc: gdb@sources.redhat.com Content-Transfer-Encoding: 7bit From: Jason Molenda Subject: Re: STL containers Date: Thu, 15 Jul 2004 19:49:00 -0000 To: sliwa@euv-frankfurt-o.de X-SW-Source: 2004-07/txt/msg00182.txt.bz2 On Jul 15, 2004, at 12:05 PM, Przemyslaw Sliwa wrote: > Is it possible to display a content of the STL containers by gdb? In the Apple integrated development environment (Xcode), we handled this in two ways. One, we added a "print for debugger" class to many of the standard Objective-C classes, and two, our UI has a "custom data formatters" feature. For objects supporting the "print for debugger" method, we have a "print-object" or "po" command in gdb which invokes taht method on a given object. The print for debugger methods prints the object's contents to stdout in some human-meaningful way. For the custom data formatters, our debugger UI comes with a bunch of pre-canned formatters. For a simple structure, like a structure that represents the height and width of a rectangle (with structure data member names "height" and "width"), you'd write width=%width%, height=%height%, and in the UI the variable summary field looks like "width=100, height=150". gdb is just grabbing the children of a varobj - very fast. The custom data formatters also allow you to make inferior function calls to extract information from objects that don't have a simple representation. We provide these custom data formatters for the main classes in our graphics frameworks. We don't provide them for STL yet, but the point of this feature was that it'll be easy to add them for STL classes in the future as well. (and users can easily write their own custom data formatters for STL or their own classes). Unfortunately I don't think either of these approaches will help you much. The "print for debugger" method requires collaboration with the library provider. The "custom data formatters" method requires a lot of work in a debugger UI sitting above gdb. I don't think it makes much sense to try to put these kinds of facilities directly inside gdb, but that's just MHO. (in case anyone is wondering, yes, having lots of custom data formatters doing inferior function calls does slow down stepping speed. They are easily disabled in the UI and we encourage people to do so when they've got too many locals being formatted at each step.) J