[mips] When to use a proc_desc

[mips] When to use a proc_desc

[Daniel Jacobowitz]

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

Re: [mips] When to use a proc_desc

[Andrew Cagney]

I'll need to study this further, however, look at HP/UX.

That unwinder checks its equivalent PDR against the prologue, ticking 
each register off as it is encountered.

Andrew

Re: [mips] When to use a proc_desc

[Andrew Cagney]

> I'll need to study this further, however, look at HP/UX.
> 
> That unwinder checks its equivalent PDR against the prologue, ticking each register off as it is encountered.

I think the long answer is the same -- look at HP/UX.  Fetch the PDR and 
then compare it against the instructions up-to $pc to see how many of 
those stores actually occured.

Andrew

Re: [mips] When to use a proc_desc

[Daniel Jacobowitz]

On Tue, Apr 06, 2004 at 05:56:46PM -0400, Andrew Cagney wrote:
> >I'll need to study this further, however, look at HP/UX.
> >
> >That unwinder checks its equivalent PDR against the prologue, ticking each 
> >register off as it is encountered.
> 
> I think the long answer is the same -- look at HP/UX.  Fetch the PDR and 
> then compare it against the instructions up-to $pc to see how many of 
> those stores actually occured.

I think that defeats the point of having the proc_desc in the first
place.  If we're only going to acknowledge register saves that we can
'easily' find, then why bother reading any of this out of the proc_desc
at all?

That would man the only useful proc_desc would b one which said fewer
registers were saved than really were, i.e. you could use them to
terminate the backtrace but not much else.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [mips] When to use a proc_desc

[Mark Kettenis]

   Date: Tue, 6 Apr 2004 17:58:10 -0400
   From: Daniel Jacobowitz <drow@false.org>

   On Tue, Apr 06, 2004 at 05:56:46PM -0400, Andrew Cagney wrote:
   > >I'll need to study this further, however, look at HP/UX.
   > >
   > >That unwinder checks its equivalent PDR against the prologue, ticking each 
   > >register off as it is encountered.
   > 
   > I think the long answer is the same -- look at HP/UX.  Fetch the PDR and 
   > then compare it against the instructions up-to $pc to see how many of 
   > those stores actually occured.

   I think that defeats the point of having the proc_desc in the first
   place.  If we're only going to acknowledge register saves that we can
   'easily' find, then why bother reading any of this out of the proc_desc
   at all?

Because it allows one to determine where the prologue actually ends,
which is after all registers described by the descriptor have been
saved.

Mark

Re: [mips] When to use a proc_desc

[Daniel Jacobowitz]

On Wed, Apr 07, 2004 at 01:33:34AM +0200, Mark Kettenis wrote:
>    Date: Tue, 6 Apr 2004 17:58:10 -0400
>    From: Daniel Jacobowitz <drow@false.org>
> 
>    On Tue, Apr 06, 2004 at 05:56:46PM -0400, Andrew Cagney wrote:
>    > >I'll need to study this further, however, look at HP/UX.
>    > >
>    > >That unwinder checks its equivalent PDR against the prologue, ticking each 
>    > >register off as it is encountered.
>    > 
>    > I think the long answer is the same -- look at HP/UX.  Fetch the PDR and 
>    > then compare it against the instructions up-to $pc to see how many of 
>    > those stores actually occured.
> 
>    I think that defeats the point of having the proc_desc in the first
>    place.  If we're only going to acknowledge register saves that we can
>    'easily' find, then why bother reading any of this out of the proc_desc
>    at all?
> 
> Because it allows one to determine where the prologue actually ends,
> which is after all registers described by the descriptor have been
> saved.

Hmm, you're saying - scan the function until we have seen all the
marked registers saved and then stop scanning for more saves?  That's
interesting, but I'm not sure how useful it is.  It's very different
from the way we use proc_desc's now.  I'll have to think about it.

Or just punt, rip out the GAS .pdr support, and add dwarf2 CFI support;
it should just be a matter of flipping the switch now.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer