This is the mail archive of the
mailing list for the GCC project.
Re: HP-PA ABI issues - framepointer handling
- To: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- Subject: Re: HP-PA ABI issues - framepointer handling
- From: law at redhat dot com
- Date: Fri, 10 Nov 2000 11:13:47 -0700
- cc: gcc at gcc dot gnu dot org, bosch at gnat dot com
- Reply-To: law at redhat dot com
In message <200010191939.PAA04817@hiauly1.hia.nrc.ca>you write:
> HP also doesn't follow its own 32 bit ABI. For non leaf procedures,
> HP cc saves the return pointer and adjusts the stack for the new frame.
> It doesn't save sp at SP-0 or the previous sp at SP-4. The previous is
> only required by the ABI if the current frame is noncontiguous with the
> previous frame, has a variable size or is used with the static link (SP-16)
If I recall correctly, the unwinding conventions do not mandate that you save
the current or previous stack pointer, only that if you do save it, that it
gets saved into a specific location within the frame.
Similarly, if I recall correctly, the existence one of those two markers
in the frame is also used by the unwinder library to indicate that we've
hit the outermost frame in the call chain. I don't recall that being in
the unwind document, but it's been some time since I looked at it.
> Per the ABI, SP-0 is is supposed to contain the stack pointer (it should
> point to the next available address). I agree that stashing the old frame
> pointer in this location seems wrong but since HP doesn't use this location
> it is probably ok. The only question that I have is r3 set properly in
> main. It should be easy to unwind gcc code using r3. Note r3 is restored
> in the epilogue.
You can't depend on r3 being available as the frame pointer -- it will be
optimized away in most functions if you turn on the optimizer.
> The 64 bit ABI is different and I don't know what we're doing there.
It's radically different :-)