From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30695 invoked by alias); 18 Apr 2006 21:35:08 -0000 Received: (qmail 30686 invoked by uid 22791); 18 Apr 2006 21:35:08 -0000 X-Spam-Check-By: sourceware.org Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 18 Apr 2006 21:35:06 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id 4A72C48CC09; Tue, 18 Apr 2006 17:35:04 -0400 (EDT) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21046-01-9; Tue, 18 Apr 2006 17:35:04 -0400 (EDT) Received: from [127.0.0.1] (dhcp6.gnat.com [205.232.38.246]) by nile.gnat.com (Postfix) with ESMTP id 1640248CBD5; Tue, 18 Apr 2006 17:35:04 -0400 (EDT) Message-ID: <44455B87.2020800@adacore.com> Date: Wed, 19 Apr 2006 06:08:00 -0000 From: Robert Dewar User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Jim Ingham CC: Vladimir Prus , gdb@sources.redhat.com Subject: Re: MI: performance of getting stack arguments References: <1CE7391B-7261-49BD-9068-89C201F555DE@apple.com> <444539D9.80805@adacore.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00254.txt.bz2 Jim Ingham wrote: > > > > 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. Gosh I would find this horrible. For example, a very common thing for me is to debug a crash in the gigi section of GNAT. I need to quickly loook down the call stack to find the most recent reference to a routine with a parameter gnat_node to find the corresponding node in the front end tree. It would be very painful to iterate frame by frame to find 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. Yes, well I agree the GUI requirements are quite different indeed. I only want to see the call stack when I need it and not all the time (I don't use a GUI interface to GDB, I prefer to use it in command line mode). > > 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... Seems reasonable to have a much more streamlined call stack visible all the time, and a special command to decorate it with parameter values. > > Jim