Re: [RFC/RFA/hppa] unwind pc in bottom frame using correct register

[Joel Brobecker <brobecker at adacore dot com>]

Thanks for the feedback,

> > --- hppa-tdep.c	1 Dec 2004 06:54:56 -0000	1.183
> > +++ hppa-tdep.c	4 Dec 2004 04:15:30 -0000
> > @@ -2185,6 +2185,12 @@ hppa_unwind_dummy_id (struct gdbarch *gd
> >  static CORE_ADDR
> >  hppa_unwind_pc (struct gdbarch *gdbarch, struct frame_info *next_frame)
> >  {
> > +  /* If unwinding the PC from the sentinel frame, then which register
> > +     to read depends on the value of the status register.  Use
> > +     hppa_target_read_pc(), it knows where to get the PC.  */
> > +  if (target_has_execution && frame_relative_level (next_frame) < 0)
> > +    return hppa_target_read_pc (inferior_ptid);
> > +
> >    return frame_unwind_register_signed (next_frame, HPPA_PCOQ_HEAD_REGNUM) & ~3;
> >  }
> 
> this is wrong... perhaps you can do:
> 
>   if (frame_unwind_register_signed (next_frame, HPPA_FLAG_REGNUM) & 2)
>     pc = frame_unsigned_register_signed (next_frame, 31);
>   else
>     pc = frame_unsigned_register_signed (next_frame, HPPA_PCOQ_HEAD_REGNUM);
>   pc &= ~3;
>   return pc;


:-(

Almost works. We get the first frame right, but then the backtraces
are broken because we get identical frames. This sort of makes sense
to me, since once you are past frame 0, you know which register to
unwind by inspecting the function associated to the frame (either prologue
analysis, or using the unwind info, or ...). No? So I would venture
that the SS_INSYSCALL thingy might be specific to the innermost frame?

With your patch, we get:

        (gdb) bt
        #0  0x7afff708 in __ksleep () from /usr/lib/libc.2
        #1  0x7afff708 in __ksleep () from /usr/lib/libc.2

or

        (gdb) bt
        #0  0x7afff760 in __kwakeup () from /usr/lib/libc.2
        #1  0x7afff760 in __kwakeup () from /usr/lib/libc.2

More on this if/when I understand hppa_target_read_pc() better.

> the bit about HPPA_FLAG_REGNUM seems to be an hpux specific thing. I
> think the syscall stub does something special so we try to return r31
> instead of pcoqh. I haven't looked at this in detail...

If it's HP/UX specific, it must be hurting hppa-linux?

> i don't like having two versions of essentially the same function
> either; Andrew mentioned in another email that this is a bug, but i
> didn't understand if he meant this is a core-gdb bug or a hppa-specific
> bug...

-- 
Joel