[RFA/mips] merge mips32_skip_prologue into mips32_scan_prologue
Tue Oct 12 21:17:00 GMT 2004
> This patch covers mips32 only for now, but mips16 will follow shortly
> once the principle is approved.
> 2004-10-11 Joel Brobecker <email@example.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
> 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.
> - 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)
- 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,
More information about the Gdb-patches