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

[Mark Kettenis <kettenis@gnu.org>]

   Date: Sat, 4 Dec 2004 00:46:24 -0800
   From: Randolph Chung <randolph@tausq.org>

Funny, I was just looking at the same issue yesterday.

   > 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?

   hrm, yes.... you are right.

   > > 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?

   well, on hppa-linux the "flags" register is always 0, so we always read
   pcoqh.

Given that this "flags" register isn't a real ISA register but an
HP-UX-specific thingy that makes sense.  For OpenBSD/NetBSD I don't
explicitly set the "flags" register, which means it'll contain 0 as
long as you don't change it.  Hmm, I think the code that looks at this
"flags" register should be moved into hppa-hpux-tdep.c.

   as you said i think we need to first better understand what is this
   SS_INSYSCALL thing....

Well, I've never seen the HP-UX source code, but it seems that the
pcoqh and pcoqt returned by ttrace(2) when the program being debugged
is in a system call, are the pcoqh and pcoqt for the currently running
kernel code, which are quite useless to us.  Apparently, at that stage
%r31 contains the address where the system call will return to, which
actually is what we're interested in.

Anyway, the problems Joel sees can be fixed by explicitly setting
"flags" to zero in all unwound frames.  This somehow seems the correct
approach since this "flags" register is only meaningful in the
sentinel frame.  This is implemented by the attached patch (wich will
no longer apply after Randolph's recent change, but you get the idea).

Alternatively, we can ditch this "flags" register alltogether, and let
the native code deal with it.  Unfortunately that means that any
implementations of the remote protocol will have to be changed to.

Anyway, if y'all agree I can check in something along the lines of the
patch below tomorrow.

Mark


Index: hppa-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/hppa-tdep.c,v
retrieving revision 1.183
diff -u -p -r1.183 hppa-tdep.c
--- hppa-tdep.c 1 Dec 2004 06:54:56 -0000 1.183
+++ hppa-tdep.c 4 Dec 2004 11:02:43 -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)
 {
+  ULONGEST flags;
+
+  flags = frame_unwind_register_unsigned (next_frame, HPPA_FLAGS_REGNUM);
+  if (flags & 2)
+    return frame_unwind_register_signed (next_frame, HPPA_R31_REGNUM) & ~3;
+
   return frame_unwind_register_signed (next_frame, HPPA_PCOQ_HEAD_REGNUM) & ~3;
 }
 
@@ -2413,6 +2419,18 @@ hppa_frame_prev_register_helper (struct 
       *realnump = -1;
       return;
     }
+  if (regnum == HPPA_FLAGS_REGNUM)
+    {
+      if (valuep)
+	store_unsigned_integer (valuep, 4, 0);
+
+      /* It's a computed value.  */
+      *optimizedp = 0;
+      *lvalp = not_lval;
+      *addrp = 0;
+      *realnump = -1;
+      return;
+    }
 
   trad_frame_get_prev_register (next_frame, saved_regs, regnum,
 				optimizedp, lvalp, addrp, realnump, valuep);