From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2207 invoked by alias); 22 May 2007 21:12:08 -0000 Received: (qmail 2189 invoked by uid 22791); 22 May 2007 21:12:05 -0000 X-Spam-Check-By: sourceware.org Received: from hq.tensilica.com (HELO mailapp.tensilica.com) (65.205.227.29) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 22 May 2007 21:12:00 +0000 Received: from localhost ([127.0.0.1]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1Hqbe8-0000OX-PZ; Tue, 22 May 2007 14:11:56 -0700 Received: from mailapp.tensilica.com ([127.0.0.1]) by localhost (mailapp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01234-03; Tue, 22 May 2007 14:11:56 -0700 (PDT) Received: from maxim_fc5.hq.tensilica.com ([192.168.11.68]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1Hqbe8-0000OR-B9; Tue, 22 May 2007 14:11:56 -0700 Message-ID: <46535C9B.9080009@hq.tensilica.com> Date: Tue, 22 May 2007 21:12:00 -0000 From: Maxim Grigoriev User-Agent: Thunderbird 1.5.0.9 (X11/20070102) MIME-Version: 1.0 To: Nick Roberts CC: Marc Gauthier , Ross Morley , Daniel Jacobowitz , Maxim Grigoriev , gdb@sourceware.org, Pete MacLiesh Subject: Re: Understanding GDB frames References: <4652AC74.9050100@tensilica.com> <18003.20339.498282.54928@kahikatea.snap.net.nz> In-Reply-To: <18003.20339.498282.54928@kahikatea.snap.net.nz> 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-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-05/txt/msg00123.txt.bz2 >> -var-create - @ myvar I tried it with my test case, and it did introduce an improvement working as described in b). It works in the latest GNU GDB, but it does not seem to present/implemented in, say, GNU GDB 6.3 and 6.5. We have to merge it from the top of the tree as soon as possible. Thanks for pointing to this feature. -- Maxim Nick Roberts wrote: > > It seems at the MI interface one wants a choice of whether a varobj > > is associated with: > > (a) a specific frame (goes away when function returns) > > (b) a function > > (c) a function at the same depth (which some implement) > > GDB already does something like (b) if you use: > > -var-create - @ myvar > > although it's not documented. I think this can specifically be used in the > case of recursion > > > How the distinction is made at the GUI level is a separate question. > > And what to do in the event of recursion when one selected a > > function-level varobj (b) is also an interesting question -- perhaps > > it always refers to the topmost instance (or to theseparately selected > > instance if the currently selected stack depth is to that function). > > > > That way, (b) and (c) have less performance impact, and one of them > > could be the default. And (a) being optional, could be fully supported > > like watchpoints by setting a breakpoint at the return PC, even though > > it has a performance hit (especially in the presence of recursion). > > > > And perhaps MI docs could even document this ;-) > > If you want this functionality in GDB then I think you will have to contribute > it. > >