From: Jens Remus <jremus@linux.ibm.com>
To: binutils@sourceware.org, Indu Bhagat <indu.bhagat@oracle.com>
Cc: Jens Remus <jremus@linux.ibm.com>,
Andreas Krebbel <krebbel@linux.ibm.com>
Subject: [RFC PATCH v3 0/2] s390: Initial support to generate SFrame info from CFI directives in assembler
Date: Fri, 12 Apr 2024 18:36:23 +0200 [thread overview]
Message-ID: <20240412163625.965517-1-jremus@linux.ibm.com> (raw)
As suggested by Indu I have split my RFC V2 patch series to add initial
support to generate SFrame information on s390x into:
1. A separate series consisting of all the generic preparatory cleanups,
enhancements, and fixes to the generation of SFrame information
in the assembler: "[PATCH v3 00/15] sframe: Enhancements to SFrame
info generation".
2. This RFC series on top with the actual "s390: Initial support
to generate SFrame info from CFI directives in assembler"
Since the original patch series was at V2 I am sending both as V3.
This patch series adds initial support to the assembler on s390x to
generate SFrame stack trace information from CFI directives. It is
largely based on the respective AArch64 support.
Please be aware that the SFrame support for s390x provided by patches
1 and 2 of this series still has some open issues, which need to be
addressed.
Any ideas or assistance to overcome the current SFrame limitations
listed below and in the patch description are very welcome.
Patch 1 adds initial support to the assembler on s390x to generate
SFrame stack trace information from CFI directives. Due to differences
in the s390x ELF ABI [1] compared to the AArch64 and x68 AMD64 ELF ABIs
and the simplified assumptions of the current SFrame format V2 there
are several unresolved issues (see also patch description):
- GCC on s390x may save the frame pointer (FP; r11) and/or return
address (RA; r14) registers in other registers (e.g. floating-point
registers) instead of saving them on the stack. SFrame currently only
supports FP/RA tracking on the stack.
GCC only does so in leaf-functions. That are functions that do not
call any other functions. Therefore they are guaranteed to only ever
be the topmost function on the call stack.
This is addressed by patch 2, which extends SFrame with limited
support to represent FP/RA saved in another register on s390x.
- The s390x ELF ABI does not designate a frame pointer register number.
Currently GCC and clang mostly use register r11.
This could be addressed by designating r11 as frame-pointer register
in the s390x ELF ABI in a SFrame compatibility section.
- GCC GCC be observed to use r14 as frame-pointer register in the stack
clash protector in the function prologue. This guarantees that the
function is toplevel on the call stack during this non-default frame-
pointer use.
This could be addressed by changing GCC to use the "default" frame-
pointer register r11. Another option would be to extend SFrame
with limited support to track a non-SP/FP CFA base register number on
s390x.
- Glibc uses non-default frame-pointer register r12 in two instances.
This most likely can be addressed by chaning glibc to use the default
frame-pointer register r11 instead.
- Glibc mcount() / fentry() use non-default return-adress register r0.
This cannot be changed, but the use of Linux Kernel perf together
with profiling can be documented as incompatible on s390x.
- GCC on s390x may copy the return address (RA) from register r14 to
another register and even use that to return to the caller.
Effectively this is just a specialization of the first bullet and
is addressed by patch 2.
- GCC may produce code and CFI where the FP is saved on the stack
while the RA is not. SFrame currently cannot represent this.
See the respective patch in my separate preparatory patch series.
This can be addressed by enhancing SFrame to represent this case.
I will send two alternative options to achieve this as RFC soon.
Patch 2 (new) extends SFrame with limited support to represent FP/RA
saved in another register on s390x. Functions may use this only while
they are the toplevel function on the call stack. That is for instance
in leaf-functions and in the function prologue and epilogue.
[1] ELF ABI s390x Supplement:
https://github.com/IBM/s390x-abi/releases
Changes v3 -> v2:
- New patch as noted above and in the patch notes.
Changes v1 -> v2:
- Resolved a regression reported by Linaro-TCWG-CI on AArch64 in one of
the generic ld SFrame test cases. The test case contained a
.cfi_def_cfa directive, specifying a CFA base register number that is
not necessarily a SFrame SP/FP register number on all architectures.
This caused the changes from patch 6 to skip SFrame FDE generation on
AArch64 (and s390x aswell) with a warning, causing the test case to
fail.
Thanks and regards,
Jens
Jens Remus (2):
s390: Initial support to generate .sframe from CFI directives in
assembler
s390: SFrame track FP/RA saved in register
gas/config/tc-s390.c | 55 +++++++++++++++++++
gas/config/tc-s390.h | 31 +++++++++++
gas/gen-sframe.c | 37 ++++++++++++-
.../gas/cfi-sframe/cfi-sframe-s390-1.d | 23 ++++++++
.../gas/cfi-sframe/cfi-sframe-s390-1.s | 37 +++++++++++++
.../gas/cfi-sframe/cfi-sframe-s390-2.d | 23 ++++++++
.../gas/cfi-sframe/cfi-sframe-s390-2.s | 37 +++++++++++++
.../gas/cfi-sframe/cfi-sframe-s390-3.d | 22 ++++++++
.../gas/cfi-sframe/cfi-sframe-s390-3.s | 15 +++++
.../gas/cfi-sframe/cfi-sframe-s390-4.d | 21 +++++++
.../gas/cfi-sframe/cfi-sframe-s390-4.s | 6 ++
.../gas/cfi-sframe/cfi-sframe-s390-err-1.d | 15 +++++
.../gas/cfi-sframe/cfi-sframe-s390-err-1.s | 37 +++++++++++++
.../gas/cfi-sframe/cfi-sframe-s390-err-2.d | 15 +++++
.../gas/cfi-sframe/cfi-sframe-s390-err-2.s | 37 +++++++++++++
.../gas/cfi-sframe/cfi-sframe-s390-err-4.d | 15 +++++
.../gas/cfi-sframe/cfi-sframe-s390-err-4.s | 5 ++
.../gas/cfi-sframe/cfi-sframe-s390-err-5.d | 15 +++++
.../gas/cfi-sframe/cfi-sframe-s390-err-5.s | 22 ++++++++
.../gas/cfi-sframe/cfi-sframe-s390-err-6.d | 15 +++++
.../gas/cfi-sframe/cfi-sframe-s390-err-6.s | 15 +++++
gas/testsuite/gas/cfi-sframe/cfi-sframe.exp | 16 +++++-
include/sframe.h | 7 ++-
libsframe/doc/sframe-spec.texi | 8 ++-
libsframe/sframe-dump.c | 22 +++++++-
25 files changed, 542 insertions(+), 9 deletions(-)
create mode 100644 gas/testsuite/gas/cfi-sframe/cfi-sframe-s390-1.d
create mode 100644 gas/testsuite/gas/cfi-sframe/cfi-sframe-s390-1.s
create mode 100644 gas/testsuite/gas/cfi-sframe/cfi-sframe-s390-2.d
create mode 100644 gas/testsuite/gas/cfi-sframe/cfi-sframe-s390-2.s
create mode 100644 gas/testsuite/gas/cfi-sframe/cfi-sframe-s390-3.d
create mode 100644 gas/testsuite/gas/cfi-sframe/cfi-sframe-s390-3.s
create mode 100644 gas/testsuite/gas/cfi-sframe/cfi-sframe-s390-4.d
create mode 100644 gas/testsuite/gas/cfi-sframe/cfi-sframe-s390-4.s
create mode 100644 gas/testsuite/gas/cfi-sframe/cfi-sframe-s390-err-1.d
create mode 100644 gas/testsuite/gas/cfi-sframe/cfi-sframe-s390-err-1.s
create mode 100644 gas/testsuite/gas/cfi-sframe/cfi-sframe-s390-err-2.d
create mode 100644 gas/testsuite/gas/cfi-sframe/cfi-sframe-s390-err-2.s
create mode 100644 gas/testsuite/gas/cfi-sframe/cfi-sframe-s390-err-4.d
create mode 100644 gas/testsuite/gas/cfi-sframe/cfi-sframe-s390-err-4.s
create mode 100644 gas/testsuite/gas/cfi-sframe/cfi-sframe-s390-err-5.d
create mode 100644 gas/testsuite/gas/cfi-sframe/cfi-sframe-s390-err-5.s
create mode 100644 gas/testsuite/gas/cfi-sframe/cfi-sframe-s390-err-6.d
create mode 100644 gas/testsuite/gas/cfi-sframe/cfi-sframe-s390-err-6.s
--
2.40.1
next reply other threads:[~2024-04-12 16:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-12 16:36 Jens Remus [this message]
2024-04-12 16:36 ` [RFC PATCH v3 1/2] s390: Initial support to generate .sframe " Jens Remus
2024-04-12 16:36 ` [RFC PATCH v3 2/2] s390: SFrame track FP/RA saved in register Jens Remus
2024-04-16 16:07 ` Jens Remus
2024-04-23 0:26 ` [RFC PATCH v3 0/2] s390: Initial support to generate SFrame info from CFI directives in assembler Indu Bhagat
2024-04-25 7:54 ` Indu Bhagat
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=20240412163625.965517-1-jremus@linux.ibm.com \
--to=jremus@linux.ibm.com \
--cc=binutils@sourceware.org \
--cc=indu.bhagat@oracle.com \
--cc=krebbel@linux.ibm.com \
/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).