[mips] When to use a proc_desc

[Daniel Jacobowitz <drow at false dot org>]

find_proc_desc has this bit of dead code in it - next_frame is never NULL:

      /* IF this is the topmost frame AND
       * (this proc does not have debugging information OR
       * the PC is in the procedure prologue)
       * THEN create a "heuristic" proc_desc (by analyzing
       * the actual code) to replace the "official" proc_desc.
       */
      if (next_frame == NULL)
        { 

This used to work (and was necessary).  Nowadays, the equivalent check would
be:
 frame_relative_level (next_frame) < 0

and if you really wanted to capture the intent of the original check, you'd
also need:
	get_frame_type (next_frame) != NORMAL_FRAME

Obviously, as we just discussed with my other patch, the point is to avoid
this grubbing up the chain.  But proc_desc's have no way to verify that
things have already been saved, so we just lose out right now.  This
corresponds to several failures in the testsuite on MIPS GNU/Linux (along
with a couple of related problems, which have less objectionable solutions).

Basically, if the current frame has not been running long enough to save all
its registers, the proc_desc can lead us easily down an unwinding rathole;
it's inherently unreliable because it has no prologue end marker.  How can
we handle this?

Eventually I want to turn on DWARF-2 unwinding support in GDB, at which
point we may not want to support GAS's .pdr at all (even if we have to
continue supporting it for some other MIPS target).  But in the meantime I'd
like to fix the regressions in it.


BTW, even in_prologue is not a good enough check, with optimized code. I
have several testcases where registers are not saved until "after" the
prologue.  But the checks in mips32_decode_reg_save are [generally] good
enough for this.  So that's a recent improvement over the previous code.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer