From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21831 invoked by alias); 24 Jul 2007 18:22:13 -0000 Received: (qmail 21820 invoked by uid 22791); 24 Jul 2007 18:22:12 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 24 Jul 2007 18:22:10 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id D6EA1982CF; Tue, 24 Jul 2007 18:22:09 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id B88E2982BA; Tue, 24 Jul 2007 18:22:09 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1IDP1L-0004xt-LB; Tue, 24 Jul 2007 14:22:07 -0400 Date: Tue, 24 Jul 2007 18:34:00 -0000 From: Daniel Jacobowitz To: Michael Eager Cc: gdb@sources.redhat.com Subject: Re: frame cache Message-ID: <20070724182207.GB18953@caradoc.them.org> Mail-Followup-To: Michael Eager , gdb@sources.redhat.com References: <46A63051.7060208@eagercon.com> <46A63209.4010405@eagercon.com> <20070724171711.GB15843@caradoc.them.org> <46A64079.2010704@eagercon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46A64079.2010704@eagercon.com> User-Agent: Mutt/1.5.15 (2007-04-09) 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-07/txt/msg00177.txt.bz2 On Tue, Jul 24, 2007 at 11:10:01AM -0700, Michael Eager wrote: > This seems odd. The function is _analyze_prologue() > not _analyze_part_of_a_prologue(). The prologue isn't going > to change depending on where the program stopped. _skip_prologue() > can return a pc based on whatever a complete analysis reveals. > > In i386, for example, the "pc limit" (called current_pc) passed > to i386_analyze_prologue() is 0xffffffff. Sparc is similar. > Neither seem to restrict how far the analyze_prologue function scans. Yes. But when you are analyzing the prologue for a frame cache, it is important to restrict it to the current PC. Otherwise obviously bad things happen when you're stopped on the first or second instruction of the function. So the result of that analysis is not always the same for a given function. > I do see that some targets merge skip_prologue and analyze_prologue. > Are there other methods? It would seem to me that for any function > that has DWARF data, one can locate the end of the prologue without > reading data from the target. I don't see any target which does this. Some targets found it easier to have two separate methods. Others use line number info, or some combination - e.g. mips_skip_prologue -> skip_prologue_using_sal. Nothing tries to use the .debug_line prologue flag, since GCC doesn't generate it yet. -- Daniel Jacobowitz CodeSourcery