From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: Jakub Jelinek <jakub@redhat.com>
Cc: Segher Boessenkool <segher@kernel.crashing.org>,
Paul Koning <paulkoning@comcast.net>,
gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Turn on LRA on all targets
Date: Fri, 16 Feb 2024 17:01:45 +0000 (GMT) [thread overview]
Message-ID: <alpine.DEB.2.21.2402161434480.3971@angie.orcam.me.uk> (raw)
In-Reply-To: <Zc9xqrWm/8g+hRkV@tucnak>
On Fri, 16 Feb 2024, Jakub Jelinek wrote:
> > There is no function prologue to optimise in the VAX case, because all
> > the frame setup has already been made by the CALLS instruction itself in
> > the caller. The first machine instruction of the callee is technically
> > already past the "prologue". And then RET serves as the whole function
> > "epilogue".
>
> So, what is the problem with DWARF unwinding? Just make sure to emit
> appropriate instructions describing the saving of the corresponding
> registers at specific points based on CFA at the start of the function
> (so that it appears in CIE instructions) and that should be all that is
> needed, no?
I may not remember all the issues correctly offhand as it's been a while
since I looked into it, but as I recall DWARF handling code has not been
prepared for all the frame to have been already allocated and initialised
at a function's entry point, and also at least DWARF-4 is IIRC required to
have statics at offsets positive from FP (for a stack growing downwards).
There was an issue about restoring the caller's value of SP too, which is
callee's AP+4*(*AP)+4 (AP being the argument pointer, which is a hardreg,
pointing at #arguments), or alternatively it can be calculated as the sum
of FP, the fixed frame size (20), the variable frame size (4*#statics,
recorded as a register mask in a 12-bit field at *(FP+6)), the #arguments
slot (4), and the argument space size (4*#arguments). Obviously the
former calculation is easier to make (#arguments has to be zero-extended
from bits 7:0).
FAOD the #arguments slot is filled by the CALLS instruction at call time
and can vary between callers obviously for varargs, but also cases such as
open(2), so to reconstruct the caller's SP you always need to examine the
actual stack frame, and it does not appear to be supported by libgcc DWARF
EH code as it stands.
I've left out stack realignment stuff or CALLG instruction support from
the consideration above, as we don't handle these features in our psABI,
all of which have provisions for from hardware in the stack frame.
As I say I may have missed or confused something, and anyway I'll take
another stab at it, hopefully soon.
Maciej
next prev parent reply other threads:[~2024-02-16 17:01 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-23 16:47 Segher Boessenkool
2023-04-23 17:01 ` Jeff Law
2023-04-23 20:23 ` Segher Boessenkool
2023-04-24 8:42 ` Andreas Schwab
2023-04-23 18:36 ` Paul Koning
2023-04-23 20:19 ` Segher Boessenkool
2023-04-23 18:56 ` Maciej W. Rozycki
2023-04-23 20:33 ` Segher Boessenkool
2023-05-15 21:09 ` Maciej W. Rozycki
2023-05-15 21:16 ` Sam James
2024-02-15 19:34 ` Sam James
2024-02-15 22:56 ` Segher Boessenkool
2024-02-16 1:41 ` Paul Koning
2024-02-16 10:22 ` Segher Boessenkool
2024-02-15 22:21 ` Paul Koning
2024-02-16 11:34 ` Maciej W. Rozycki
2024-02-16 13:47 ` Segher Boessenkool
2024-02-16 14:23 ` Maciej W. Rozycki
2024-02-16 14:31 ` Jakub Jelinek
2024-02-16 17:01 ` Maciej W. Rozycki [this message]
2024-02-17 0:38 ` Maciej W. Rozycki
2024-02-16 14:50 ` Paul Koning
2023-04-23 21:06 ` Uros Bizjak
2023-04-24 9:17 ` Segher Boessenkool
2023-04-24 9:46 ` Uros Bizjak
2023-04-29 14:38 ` Segher Boessenkool
2023-04-24 8:19 ` Richard Biener
2023-04-24 9:44 ` Segher Boessenkool
2023-04-30 19:52 ` Jeff Law
2023-04-29 13:37 Roger Sayle
2023-04-29 15:06 ` Jeff Law
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.21.2402161434480.3971@angie.orcam.me.uk \
--to=macro@orcam.me.uk \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=paulkoning@comcast.net \
--cc=segher@kernel.crashing.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).