This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Modernize HP-UX core file handling


> found where all registers are saved. We know before scanning the
> instrunctions that the SP was saved, but we don't know that the register
> containing the old SP has itself been saved on the stack.

Huh?  GCC uses r3 as the frame pointer.  When a frame pointer is
needed, SAVE_SP is set.  When SAVE_SP is set, current GCC versions
save the old SP at SP-4.  The SP-4 is set in the prologue and whenever
a dynamic stack allocation is performed.  Unfortunately, old versions
of GCC don't correctly save the old SP at SP-4.  However, r3 always
contains the old SP when SAVE_SP is set.  HP compilers don't set
SAVE_SP.  The SP-4 support was added to GCC to fix a problem with
the HP-UX unwind library.

I'm not surprised that gdb didn't see the save at SP-4 as this is
a relatively new GCC feature under HP-UX (this isn't done under linux).
This was for better support of the frame marker.  Note the frame
marker moves in a dynamic stack allocation (i.e, the old SP is always
at SP-4).  Thus, if SAVE_SP is set and you see a save to SP-4 in
the prologue, the old SP can always be found at SP-4.

Since r3 is a callee-saves register, it has to be saved on the stack
when SAVE_SP is set in the unwind info.

Hope that helps.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]