From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-24964-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 27936 invoked by alias); 18 Apr 2006 19:11:35 -0000
Received: (qmail 27925 invoked by uid 22791); 18 Apr 2006 19:11:34 -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 19:11:32 +0000
Received: from localhost (localhost [127.0.0.1]) 	by filtered-nile.gnat.com (Postfix) with ESMTP id 0692648CDC6; 	Tue, 18 Apr 2006 15:11:26 -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 17859-01; Tue, 18 Apr 2006 15:11:25 -0400 (EDT)
Received: from [127.0.0.1] (dhcp6.gnat.com [205.232.38.246]) 	by nile.gnat.com (Postfix) with ESMTP id A4E0048CC4F; 	Tue, 18 Apr 2006 15:11:25 -0400 (EDT)
Message-ID: <444539D9.80805@adacore.com>
Date: Tue, 18 Apr 2006 21:35:00 -0000
From: Robert Dewar <dewar@adacore.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Jim Ingham <jingham@apple.com>
CC: Vladimir Prus <ghost@cs.msu.su>,  gdb@sources.redhat.com
Subject: Re: MI: performance of getting stack arguments
References: <e2331r$cbr$1@sea.gmane.org> <1CE7391B-7261-49BD-9068-89C201F555DE@apple.com>
In-Reply-To: <1CE7391B-7261-49BD-9068-89C201F555DE@apple.com>
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: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2006-04/txt/msg00252.txt.bz2

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!