From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19966 invoked by alias); 23 May 2007 01:01:08 -0000 Received: (qmail 19895 invoked by uid 22791); 23 May 2007 01:01:07 -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 01:01:04 +0000 Received: from localhost ([127.0.0.1]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1HqfDq-0001VS-LX; Tue, 22 May 2007 18:01:02 -0700 Received: from mailapp.tensilica.com ([127.0.0.1]) by localhost (mailapp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04030-03; Tue, 22 May 2007 18:01:02 -0700 (PDT) Received: from maxim_fc5.hq.tensilica.com ([192.168.11.68]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1HqfDp-0001VA-KK; Tue, 22 May 2007 18:01:01 -0700 Message-ID: <4653924D.5030304@hq.tensilica.com> Date: Wed, 23 May 2007 01:01:00 -0000 From: Maxim Grigoriev User-Agent: Thunderbird 1.5.0.9 (X11/20070102) MIME-Version: 1.0 To: Jim Blandy CC: gdb@sourceware.org, Marc Gauthier , Ross Morley Subject: Re: Understanding GDB frames References: <46521C04.7040405@hq.tensilica.com> <465341B8.9060208@hq.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/msg00130.txt.bz2 >> I think distinguishing frames can be improved by using the third >> argument of frame_id, which is a "special address". Most of the >> implementations don't use it. > What would you put there? Let's look at the following frame ID template: { stack_addr = code_addr = special_addr = (Frame_Level << 24) | ( & 0xffffff) } Where Frame_Level == frame_relative_level (frame) & 0xff . I think it's going to cover 1) Recursion ; 2) void foo (void) { } void bar (void) { } main () { int i; for (i = 0; i < 2; i++) { void (*f) (void) = i ? foo : bar; f (); } } 3) { foo(); foo(); } 4) All the cases when function is called from different levels; But, this case is still a problem : 5) for (i = 0; i < 10; i++) foo (); Anyway, doesn't it look like a reasonably inexpensive improvement ? -- Maxim Jim Blandy wrote: > Maxim Grigoriev writes: > >>> It's worth pointing out that the 'PC' in a frame ID isn't the current >>> PC within the function. It's always the PC of the function's entry >>> point, so that stepping within a function doesn't cause the frame ID >>> to change. Usually it's a PC value returned by 'frame_func_unwind', >>> which takes care of calling get_pc_function_start for you. >>> >> We've been using a function return address instead of the PC of the >> function's entry, and it works just fine. >> > > Hmm. Consider: > > void foo (void) { } > void bar (void) { } > > main () > { > int i; > > for (i = 0; i < 2; i++) > { > void (*f) (void) = i ? foo : bar; > f (); > } > } > > So, main will call bar first, then foo. Both calls will have > identical incoming sp's, and identical return addresses. > > Using the callee's entry point is more direct; there's less > opportunity for things to go wrong. And the rest of GDB is already > working to cover up the shortcomings of that approach. :) > > >> I think distinguishing frames can be improved by using the third >> argument of frame_id, which is a "special address". Most of the >> implementations don't use it. >> > > What would you put there? > >