Re: [RFC PATCH 0/1] sframe: Represent FP without RA on stack (bitmap)

[Indu Bhagat <indu.bhagat@oracle.com>]

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.

I have two suggestions to resolve this issue of "FP without RA on 
stack".  I will reply on the other thread.

> 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(-)
>