Re: RFA: general prologue analysis framework

["Nathan J. Williams" <nathanw@wasabisystems.com>]

Jim Blandy <jimb@redhat.com> 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