Re: [RFA/mips] merge mips32_skip_prologue into mips32_scan_prologue

[Andrew Cagney <cagney@gnu.org>]

> This patch covers mips32 only for now, but mips16 will follow shortly
> once the principle is approved.
> 
> 2004-10-11  Joel Brobecker  <brobecker@gnat.com>
> 
>         * mips-tdep.c (mips32_scan_prologue): Merge code from
>         mips32_skip_prologue.  Now return the address of the first
>         instruction past the function prologue.
>         (mips32_skip_prologue): Remove.  No longer necessary.
>         (mips16_skip_prologue): Add parameter end_pc instead of
>         computing it.
>         (mips_skip_prologue): Compute the upper limit for the
>         prologue scanning. Update call to mips16_skip_prologue.
>         Replace call to mips32_skip_prologue by call to
>         mips32_scan_prologue.
> 
> A few remarks:
> 
>   - The change of prototype for mips16_skip_prologue is not really
>     necessary, as this function will be removed at the next iteration.
>     It was just a change I made to make it clearer for me where the
>     code was going, at how I was to avoid code duplication. I can
>     remove this change from this patch, if necessary.

M'kay.

>   - What do you think of this FIXME?
> 
> +         /* FIXME: brobecker/2004-10-10: Can't we just break out of this
> +            loop now?  Why would we need to continue scanning the function
> +            instructions?  */
> +         if (end_prologue_addr == 0)
> +           end_prologue_addr = cur_pc;
> 
>     Running the testsuite on our IRIX machine is a bit longish
>     right now (we have nightly builds running right now), so I didn't
>     give this idea a short at the testsuite yet. But I don't see any
>     reason for us to keep going in this loop if we've determined that
>     we're past the prologue. Unless we want to take into account any
>     subsequent instructions in the function body that would move the
>     location of registers, etc? I can test this idea tomorrow, when
>     the CPU usage is lighter on the machine.

My understanding is that there are two cases:

- skipping the prologue (i.e., finding the end)
Yes, bail

- scanning the prologue
historically scanners had this habit of scanning beyond the 
end-of-prologue (and sometimes beyond the current PC -> big oops for 
that one!), sometimes it was a mistake, sometimes it was deliberate 
trying to handle optomized code

GDB should behave consistently, so yes, I think it should bail.  Complex 
prologues can be handled by mdebug or dwarf2.

> Tested on mips-irix, no regression. OK to commit?

Yes, and also ok to follow-on patches at this incremental level.

thanks for this,
Andrew