This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA/mips] merge mips32_skip_prologue into mips32_scan_prologue


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]