From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5501 invoked by alias); 23 May 2007 02:24:58 -0000 Received: (qmail 5415 invoked by uid 22791); 23 May 2007 02:24:57 -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; Wed, 23 May 2007 02:24:55 +0000 Received: from localhost ([127.0.0.1]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1HqgWy-0000NY-2h; Tue, 22 May 2007 19:24:52 -0700 Received: from mailapp.tensilica.com ([127.0.0.1]) by localhost (mailapp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25899-09; Tue, 22 May 2007 19:24:51 -0700 (PDT) Received: from nose.hq.tensilica.com ([192.168.11.18]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1HqgWx-0000NS-L4; Tue, 22 May 2007 19:24:51 -0700 Message-ID: <4653A5F3.60503@tensilica.com> Date: Wed, 23 May 2007 02:24:00 -0000 From: Ross Morley User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 MIME-Version: 1.0 To: Jim Blandy CC: Maxim Grigoriev , gdb@sourceware.org, Marc Gauthier , Pete MacLiesh Subject: Re: Understanding GDB frames References: <46521C04.7040405@hq.tensilica.com> <465341B8.9060208@hq.tensilica.com> <46538818.1050601@tensilica.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; 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/msg00132.txt.bz2 Jim Blandy wrote: >Ross Morley writes: > > >>Jim Blandy wrote: >> >> >>>After I'd sent my last post I realized that, of course, the "entry >>>point PC" approach fails in the (I'd guess) more common case that the >>>"return address PC" does not: >>> >>> void foo (void) {} >>> main () { foo (); foo (); } >>> >>>Perhaps the best approach is to use both the return address and the >>>entry point in the frame ID. If either have changed, it's certainly a >>>new frame. >>> >>> >>> >>> >>Well not quite certainly, eg. >> >> void bar (void) {} >> void foo (void) { bar (); } >> main () { foo (); foo (); } >> >>But definitely an improvement that's easy to achieve. >> >> > >I don't follow. Is there something here where a frame's return >address and entry point change, but it's not a new frame? I'm not >claiming using both the return address and the entry point would >eliminate false positives in frame_eq, just that it restricts false >positives and does not introduce false negatives. > > > I'm sorry, I misread your post. Your "certainly" is certainly right. :-) We need to remember, though, that one goal is to minimize the overhead for the MI front end of having to re-create varobjs. As we get better at detecting a frame change (reduce false positives) we actually increase the overhead for the FE because it then (to be correct) needs to recreate its varobjs. We should think about solving that problem before we get too much better at detecting frame changes. Ross