From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14816 invoked by alias); 7 Oct 2005 21:30:35 -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 14760 invoked by uid 22791); 7 Oct 2005 21:30:33 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 07 Oct 2005 21:30:33 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1ENznQ-0000dl-RD; Fri, 07 Oct 2005 17:30:29 -0400 Date: Fri, 07 Oct 2005 21:30:00 -0000 From: Daniel Jacobowitz To: "Nathan J. Williams" Cc: Jim Blandy , gdb-patches@sourceware.org Subject: Re: RFA: general prologue analysis framework Message-ID: <20051007213028.GA2371@nevyn.them.org> Mail-Followup-To: "Nathan J. Williams" , Jim Blandy , gdb-patches@sourceware.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-SW-Source: 2005-10/txt/msg00064.txt.bz2 On Fri, Oct 07, 2005 at 05:24:58PM -0400, Nathan J. Williams wrote: > Short form: "What about branches?" Short answer: You're out of luck. Prologue analysis can't do this. > 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? Longer answer: This trivial example, sure, we could extend GDB to handle. But in fact I don't think it's a very useful example. Basic blocks can have more than one incoming edge, and more than one outgoing edge; reconstructing the control flow useful is not practical. If you're guaranteed that the compiler only adjusts the stack pointer by constant amounts, either in the prologue or down and then up again within a basic block, maybe it would be useful. But very few compilers behave that way. Did your compiler really give you that guarantee? -- Daniel Jacobowitz CodeSourcery, LLC