From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 060393858D38 for ; Tue, 23 Apr 2024 09:54:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 060393858D38 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 060393858D38 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=148.163.156.1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713866059; cv=none; b=GISO6p6A3NKYkzy3C+ZaYoYpzuZNEGLYyTKMrfMCatn1IU7PR4RiDMlbe2vBJkoqP24I5s1mZF7jAWoC5RfErnsPkassymHkUxQYgTNUBePnSf4nHnhChdUi0UVKNKxIw+LKgebr9CAIjOXzy2BmV9QLXQrtYKdiae8Cy0M32Yk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713866059; c=relaxed/simple; bh=uaKDB0aY5DzAo1mioq7bj+m50P1yv/48n5U3GvrkBZQ=; h=DKIM-Signature:Message-ID:Date:Subject:To:From:MIME-Version; b=agMYOLzCmSReXwe7TSvkc1uos0UG8UPmg63Ta1AKWWo2WqbS3YcSpQdQG6MLdlTdfwzocEil6aSe74uBUhcVemU7HLByylgoNPCdBiStg7mGs68MSBblOq5q2DQieMkOcbWlpUHy0Nx6JG7KpofJdBD8yCX2wQT00l29Gi0SSbc= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from pps.filterd (m0353729.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 43N7HXIF005233; Tue, 23 Apr 2024 09:54:16 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pp1; bh=g97j5BV+ykR5JiN9vXnoE7SkEs4Dr6AHYk0piFI2jxU=; b=QvsocLbPfZ7LIWgj5rBhXuQt9B4JvE+k+o6IYBduN1mChv5ek4rqBIm4/g3e8JErt/qV OustdKX4YjnGzLN3hjZku8AkB1TySmj0SgKGoE9zt9bsWNFP0TuWvTcS3oV+kVGZvROW +j0pVr8K1jMIwWRlqdd6U30DvdzGszZkWlv+l0uwIPThcB5qR3RfqLYKEWBOyjuumUS2 YKK07vYraveFwV2vGt5+nvmFYkPnruo8KLrRjWKwPQC70K2s5z4MnNibyRu8J/ocPCSd +xTzjgpSyICUHK6YA0FaXXqmktq35NOhuPoyEl+jMAFl5SpcLgfF7Bw65B9ZAd9SicqI og== Received: from ppma11.dal12v.mail.ibm.com (db.9e.1632.ip4.static.sl-reverse.com [50.22.158.219]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3xp8fa89bb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Apr 2024 09:54:15 +0000 Received: from pps.filterd (ppma11.dal12v.mail.ibm.com [127.0.0.1]) by ppma11.dal12v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 43N9XGPC028315; Tue, 23 Apr 2024 09:54:14 GMT Received: from smtprelay01.fra02v.mail.ibm.com ([9.218.2.227]) by ppma11.dal12v.mail.ibm.com (PPS) with ESMTPS id 3xmtr2cdt3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Apr 2024 09:54:14 +0000 Received: from smtpav06.fra02v.mail.ibm.com (smtpav06.fra02v.mail.ibm.com [10.20.54.105]) by smtprelay01.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 43N9s9Ix42664348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 23 Apr 2024 09:54:11 GMT Received: from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0890B20049; Tue, 23 Apr 2024 09:54:09 +0000 (GMT) Received: from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id AD35B20040; Tue, 23 Apr 2024 09:54:08 +0000 (GMT) Received: from [9.171.69.100] (unknown [9.171.69.100]) by smtpav06.fra02v.mail.ibm.com (Postfix) with ESMTP; Tue, 23 Apr 2024 09:54:08 +0000 (GMT) Message-ID: <8341b2fd-2890-4fc6-a4ea-8892be2b6ac5@linux.ibm.com> Date: Tue, 23 Apr 2024 11:54:08 +0200 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 0/1] sframe: Represent FP without RA on stack (bitmap) To: Indu Bhagat , binutils@sourceware.org Cc: Andreas Krebbel References: <20240422155905.2497883-1-jremus@linux.ibm.com> <0996b8e3-9fe3-4381-b34c-df9ef3798d67@oracle.com> From: Jens Remus Content-Language: en-US Organization: IBM Deutschland Research & Development GmbH In-Reply-To: <0996b8e3-9fe3-4381-b34c-df9ef3798d67@oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed X-TM-AS-GCONF: 00 X-Proofpoint-GUID: n_qGa0NqE6fhJ37N-XLjRi1b50zelSoN X-Proofpoint-ORIG-GUID: n_qGa0NqE6fhJ37N-XLjRi1b50zelSoN Content-Transfer-Encoding: 8bit X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-04-23_08,2024-04-22_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 clxscore=1015 suspectscore=0 mlxscore=0 priorityscore=1501 bulkscore=0 adultscore=0 mlxlogscore=694 impostorscore=0 malwarescore=0 phishscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2404010000 definitions=main-2404230026 X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Am 23.04.2024 um 01:59 schrieb Indu Bhagat: > On 4/22/24 08:59, Jens Remus wrote: >> This patch series adds support in SFrame to represent the frame pointer >> (FP) without the return address (RA) being saved on the stack (and/or on >> s390x in another register). >> >> This is the second of two proposed alternatives: >> 1. The alternative patch series uses a dummy padding offset (invalid >>     offset from CFA value of zero) as RA offset to represent FP without >>     RA on saved on the stack. >> 2. This patch series changes the SFrame FRE count field into >>     a bitmap, to convey which offsets follow the FRE. >> >> Note that it currently applies on top of my v3 patch series series that >> adds initial support to generate .sframe from CFI directives on s390x, >> although it is independent of that. >> >> A SFrame FRE currently has a 4-bit field containing the offset count >> that follow the FRE. While this could account for up to 15 offsets (or >> 16, when excluding the mandatory CFA offset from CFA base register), it >> cannot represent which of these offsets actually follow. >> >> Redefining the 4-bit count field into a 4-bit offset bitmap allows to >> track up to 4 offsets (or 5, when excluding the mandatory CFA offset >> from CFA base register). >> > > This approach, in its current form, immensely confines the future > adaptability of the format. > > My recommendation would be to avoid such changes to format where is > becomes more restrictive for future needs.  While it is generally > recommended to not add more registers to track, confining it now to 4 > (or 5) offsets now seems rather limiting. Isn't it rather confining that using a simple offset count cannot represent which of the tracked offsets follow a FRE, which effectively enforces a precedence in which they can be tracked? I just wonder whether it is really that useful to theoretically be able to track 15 (or 16) offsets with this limitation instead of just 3 (or 4) without any limitations. The number of bits could also be increased in a future SFrame version with a different FRE layout. I don't have enough knowledge of other architectures to judge, whether the s390x case of an architecture using both FP and RA tracking while not always saving both at once or restoring them individually is really exotic or might be more widespread. I would understand if changing SFrame V2 to a bitmap is too much of a change and would need to wait until the next version. Using the dummy padding offsets in V2 (on s390x) in the meantime, which are just a minor change, would be a good compromise. > I have two suggestions to resolve this issue of "FP without RA on > stack".  I will reply on the other thread. Thanks a lot for your feedback! I will follow up there. >> The main downside of this approach is that this is potentially a major >> change to the SFrame V2 format, which may require a bump to V3. The >> benefits are that (1) it does not add any dummy padding offsets, which >> would unnecessarily add bloat to the SFrame information, and that (2) >> it does not change any of the external SFrame API. >> Using a lookup table the bitmap can easily be translated into an offset >> count. Similar any logic that checks the presence of an offset can >> easily be implemented using a bit test. >> >> Note that there is a minor implementation issue with regards to the >> internal API methods (callbacks), due to the change in SFrame format >> changing a method argument from count to bitmap. >> Additionally this initial implementation lacks better naming of the >> tracked register IDs and any update of the SFrame format specification. >> >> Thanks and regards, >> Jens >> >> >> Jens Remus (1): >>    sframe: Represent FP without RA on stack >> >>   gas/gen-sframe.c   | 66 ++++++++++++++++++++++++++++------------------ >>   include/sframe.h   | 13 ++++++--- >>   libsframe/sframe.c | 51 +++++++++++++++++++++++++++-------- >>   3 files changed, 90 insertions(+), 40 deletions(-) >> > Regards, Jens -- Jens Remus Linux on Z Development (D3303) and z/VSE Support +49-7031-16-1128 Office jremus@de.ibm.com IBM IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Böblingen; Registergericht: Amtsgericht Stuttgart, HRB 243294 IBM Data Privacy Statement: https://www.ibm.com/privacy/