From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12074 invoked by alias); 7 Oct 2005 21:25:14 -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 11851 invoked by uid 22791); 7 Oct 2005 21:25:11 -0000 Received: from biscayne-one-station.mit.edu (HELO biscayne-one-station.mit.edu) (18.7.7.80) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 07 Oct 2005 21:25:11 +0000 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id j97LP2VP021267; Fri, 7 Oct 2005 17:25:02 -0400 (EDT) Received: from scrubbing-bubbles.mit.edu (SCRUBBING-BUBBLES.MIT.EDU [18.7.16.68]) (authenticated bits=56) (User authenticated as nathanw@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id j97LOxLg022837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 Oct 2005 17:24:59 -0400 (EDT) Received: (from nathanw@localhost) by scrubbing-bubbles.mit.edu (8.12.9) id j97LOww5006172; Fri, 7 Oct 2005 17:24:58 -0400 (EDT) To: Jim Blandy Cc: gdb-patches@sourceware.org Subject: Re: RFA: general prologue analysis framework References: From: "Nathan J. Williams" Date: Fri, 07 Oct 2005 21:25:00 -0000 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -3.349 X-Spam-Flag: NO X-SW-Source: 2005-10/txt/msg00063.txt.bz2 Jim Blandy writes: > If folks are interested, I can post the m32c prologue analyzer that > uses these functions, as an example of how they can be used. I would be interested. I like the general concept; I have one question about the use, based on a remark in the comments: > + Once you've reached the current PC, or an instruction that you > + don't know how to simulate, you stop. Now you can examine the > + state of the registers and stack slots you've kept track of. > + > + - To see how large your stack frame is, just check the value of the > + stack pointer register; if it's the original value of the SP > + minus a constant, then that constant is the stack frame's size. > + If the SP's value has been marked as 'unknown', then that means > + the prologue has done something too complex for us to track, and > + we don't know the frame size. Short form: "What about branches?" Long form: I recently did a port for a target CPU whose compiler didn't provide any debug information about the stack frame. I dug out their sizes at any given point by examining the code from the function entry point to the current PC, and tracking the values added or subtracted to the SP (said compiler also did not believe in adjusting the SP once on function entry, and didn't gave a frame pointer). However, I was tripped up by code kind of like: ; function entry add sp,-64 ... ... beq 1f add sp, 64 ret 1: ... ... add sp, 64 ret When my analyzer linearly plowed through the code, it would have computed the net frame size as 0 at point 1, which was wrong. I worked around this by ignoring sp adjustments right before a return instruction, but it was clunky. I wanted to implement a computation of the stack offset at each point in the function, but didn't have time. Would this framework be amenable to maintaining such a mapping? - Nathan