Home Original page

[RFC 15/28] [SFrame-V3] include: sframe: reserve 4 bits for new FDE types

Indu Bhagat indu.bhagat@oracle.com
Tue Dec 16 05:48:54 GMT 2025 
On 12/15/25 3:06 AM, Jens Remus wrote:
> On 12/15/2025 8:51 AM, Indu Bhagat wrote:
>>>> On Dec 12, 2025, at 19:20, Indu Bhagat via Binutils <binutils@sourceware.org> wrote:
>>>> On 12/11/25 9:36 AM, Jens Remus wrote:
> 
>>>>> Can this be summarize to:  Recovery rules that employ arbitrary register
>>>>> contents (other than SP/FP) are only allowed in the topmost frame?
>>>>
>>>> Yes.
> 
> ...
> 
>> The important bit is also that: For supporting the DRAP pattern, we do
>> not start tracking these additional registers (say, r10, rcx..) in
>> SFrame.  We instead rely on stack tracers to not pursue the information
>> in SFRAME_FDE_TYPE_FLEX_TOPMOST_FRAME if it is not the topmost frame.
> 
> My understanding of FLEX_TOPMOST_FRAME:
> The information therein may be always pursued as long as it does not
> reference any non-SP/FP registers.  Only referencing to non-SP/FP
> registers is limited to the topmost frame.
> 
> In case of the s390x stack clash protector, which may use the non-SP/FP
> register r14 as CFA base register, the FREs that reference r14 are
> limited to the topmost frame.  All other FREs (that do not reference
> any non-SP/FP register) can be pursued even if not the topmost frame.
> 
> Therefore I am wondering whether it would be better to change the name
> to e.g. SFRAME_FDE_TYPE_FLEXIBLE and omit the (TOPMOST_FRAME), as it
> suggests readers all of the information would be limited to topmost
> frames only, which is simply wrong.
> 

Your understanding is correct.

If SFRAME_FDE_TYPE_FLEXIBLE looks more relatable and appropriate, we can 
use SFRAME_FDE_TYPE_FLEXIBLE.

Thanks
More information about the Binutils mailing list