From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20895 invoked by alias); 18 Apr 2006 21:15:50 -0000 Received: (qmail 20886 invoked by uid 22791); 18 Apr 2006 21:15:49 -0000 X-Spam-Check-By: sourceware.org Received: from mail-out3.apple.com (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 18 Apr 2006 21:15:47 +0000 Received: from relay8.apple.com (relay8.apple.com [17.128.113.38]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id k3ILFPp6025934; Tue, 18 Apr 2006 14:15:25 -0700 (PDT) Received: from [17.201.22.240] (unknown [17.201.22.240]) by relay8.apple.com (Apple SCV relay) with ESMTP id 2E63F5BD; Tue, 18 Apr 2006 14:15:25 -0700 (PDT) In-Reply-To: <444539D9.80805@adacore.com> References: <1CE7391B-7261-49BD-9068-89C201F555DE@apple.com> <444539D9.80805@adacore.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Vladimir Prus , gdb@sources.redhat.com Content-Transfer-Encoding: 7bit From: Jim Ingham Subject: Re: MI: performance of getting stack arguments Date: Tue, 18 Apr 2006 21:37:00 -0000 To: Robert Dewar X-Mailer: Apple Mail (2.749.3) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-04/txt/msg00253.txt.bz2 On Apr 18, 2006, at 12:11 PM, Robert Dewar wrote: > Jim Ingham wrote: >> Do you really have a UI that shows the stack arguments for ALL the >> frames on the stack? That's very unusual (and visually a bit >> overwhelming, I would imagine). The usual stack display shows the >> stack with just the function names. Then clicking on any given >> stack will populate the arguments for that frame, fill the source >> window with the source for that frame, etc... This way, you only >> need to fetch the arguments for the bottom-most frame on the stack >> when you stop stepping. You would only fetch the other stack >> arguments if the user specifically requests them. > > The ordinary bt from gdb gives this info, and it would be a pain > not to have it! > I dunno. I find that having a really simple clean stack listing with just function names makes it much easier to tell where I am in the program. Most of the time that's what I want to see, not what the third argument to the function 10 frames up on the stack was. If I want that, I don't find it a problem to dial it up. And in the GUI all you have to do is click on the frame to see the source & arguments. This seems to work pretty well for folks, at least we get lots of suggestions from our users, but nobody's ever asked us to change this. Anyway, this is a "to each his own" kind of thing. But just keep in mind, when you are implementing a GUI debugger that anything you show in the UI you are pledging to update every time a step is completed. And most folks are pretty sensitive about how long it takes for each step to complete. So you do need to be a bit conservative about what you display by default. Adding to this, gdb does get slow as programs get large, which makes it even more important to be judicious. Also, in a GUI much more stuff is visible at once, so if each element is too complex then the overall result is noisy and hard to use. Visual Studio used by default to show a whole bunch of junk in the stack window (pc, args, etc.) and way back when I used it I found it really hard to look at for just this reason. According to the 2005 Online docs, you can turn all the other info off and display just the function name if you want... Jim