From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17497 invoked by alias); 14 Oct 2005 18:13:07 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 17477 invoked by uid 22791); 14 Oct 2005 18:13:02 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 14 Oct 2005 18:13:02 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j9EICxbm020345; Fri, 14 Oct 2005 14:12:59 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j9EICwV21656; Fri, 14 Oct 2005 14:12:58 -0400 Received: from theseus.home..redhat.com (vpn26-5.sfbay.redhat.com [172.16.26.5]) by devserv.devel.redhat.com (8.12.11/8.12.11) with ESMTP id j9EICuXP021801; Fri, 14 Oct 2005 14:12:57 -0400 To: Ulrich Weigand Cc: gdb-patches@sourceware.org Subject: Re: RFA: general prologue analysis framework References: <200510131748.j9DHm1eW002511@53v30g15.boeblingen.de.ibm.com> From: Jim Blandy Date: Fri, 14 Oct 2005 18:13:00 -0000 In-Reply-To: <200510131748.j9DHm1eW002511@53v30g15.boeblingen.de.ibm.com> (Ulrich Weigand's message of "Thu, 13 Oct 2005 19:48:01 +0200 (CEST)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2005-10/txt/msg00122.txt.bz2 Ulrich Weigand writes: >> It looks like your data->gpr_slot[i] array effectively serves the same >> purpose as an area. If we had generic code to scan an area and >> populate a trad_frame_cache, areas might save you code. > > Possibly, yes. I'm not sure I completely understand the pv_area code > yet -- it appears to be all based on the notion of a fixed base register; > how to you handle the situation where the base (and/or offset) used to > access the area change in the middle of the prologue? Maybe it would > be better to always base the area on the CFA ... The comment for make_pv_area was misleading. Here's a better comment: /* Create a new area, tracking stores relative to the original value of BASE_REG. Stores to constant addresses, unknown addresses, or to addresses relative to registers other than BASE_REG will trash this area; see pv_area_store_would_trash. */ struct pv_area *make_pv_area (int base_reg); So if you pass the SP as the base register, the CFA is exactly what you get. The CFA must always be a constant offset from the incoming value of the SP. The CFA is constant for a given call, and the incoming value of the SP is also a constant for a given call, simply because registers have only one value at a time. So their difference must be a constant.