This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [hppa-hpux] Signal frame unwinding support for hppa64-hp-hpux11.11
> 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