Re: [hppa-hpux] Signal frame unwinding support for hppa64-hp-hpux11.11

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> Date: Thu, 17 Nov 2005 18:04:40 +0800
> From: Randolph Chung <randolph@tausq.org>
> 
> >>2005-11-15  Randolph Chung  <tausq@debian.org>
> >>
> >>	* hppa-hpux-tdep.c (hppa_hpux_sigtramp_frame_unwind_cache): Ensure "off"
> >>	is large enough to hold 64-bit offset.  Set proper signal context offset
> >>	for 64-bit programs.  Set pc properly for signal frames.
> > 
> > 
> > Please reformat the ChangeLog entry before you commit; the lines are too long!
> 
> I can, but these lines are only 80 characters wide... why are they too
> long?

Ah, 80 characters is too long.  Emacs will wrap the line if there's
something in column 80.  Please keep it down to something like 72.

> >>Index: hppa-hpux-tdep.c
> >>===================================================================
> >>RCS file: /cvs/src/src/gdb/hppa-hpux-tdep.c,v
> >>retrieving revision 1.43
> >>diff -u -p -r1.43 hppa-hpux-tdep.c
> >>--- hppa-hpux-tdep.c	29 Oct 2005 21:31:45 -0000	1.43
> >>+++ hppa-hpux-tdep.c	15 Nov 2005 15:40:07 -0000
> >>@@ -1188,7 +1192,7 @@ hppa_hpux_sigtramp_frame_unwind_cache (s
> >>   else
> >>     {
> >>       /* Wide registers. */
> >>-      off = scptr + offsetof (save_state_t, ss_wide) + 8;
> >>+      off = scptr + offsetof (save_state_t, ss_wide.ss_64) + 8;
> >>       incr = 8;
> >>       szoff = (tdep->bytes_per_address == 4 ? 4 : 0);
> >>     }
> >>@@ -1203,11 +1207,15 @@ hppa_hpux_sigtramp_frame_unwind_cache (s
> > 
> > 
> > Hmm, why is this chunk needed?  AFAICT it shouldn't make a difference
> > and I have a preference for using a plain ss_wide).
> 
> It's not needed, but it's a bit clearer IMO. I will revert this if you
> prefer.

Actually what I'd really prefer if you'd make use of the
HPPA_HPUX_SS_XXX constants that I added when I did the HP-UX register
set support.  You'll need to move them to the start of the file, but
using them would bring us a step closer to building a HP-UX
cross-debugger.

But if you don't want to spend the time on this, then yes, I'd prefer
that you don't change ss_wide into ss_wide.ss_64.  The reason is
actually that even for 32-bit stuff the ss_wide part of save_state_t
might be used.  So I think the ss_64 part is misleading.

Mark