Re: RFA: general prologue analysis framework

[Daniel Jacobowitz <drow@false.org>]

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