This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC] Modernize HP-UX core file handling
- From: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- To: gdb-patches at sources dot redhat dot com
- Cc: randolph at tausq dot org, brobecker at adacore dot com
- Date: Thu, 16 Dec 2004 21:43:33 -0500 (EST)
- Subject: 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)