[V2 17/36] [SFrame-V3] gas: sframe: use three states for location tracking

[Jens Remus]

On 1/7/2026 9:42 AM, Indu Bhagat wrote:
> Up until now, for SFrame stack trace data generation (for default FDE
> type), tracking of two states sufficed to distinguish between the two
> cases:
>   - the tracked entity is saved on a location on stack (tracked by
>     SFRAME_FRE_ELEM_LOC_STACK)
>   - the tracked entity is in register (tracked by
>     SFRAME_FRE_ELEM_LOC_REG).

Maybe use "identified by" instead of "tracked by"?

Maybe clarify that register actually means its designated register (and
not any register) in this context:

  - the tracked entity is in its designated register
    (identified by SFRAME_FRE_ELEM_LOC_REG)

> 
> (In some sense, the distinction between the above two was the same as
> saying SFRAME_FRE_ELEM_LOC_TRACKED or SFRAME_FRE_ELEM_LOC_UNTRACKED
> respectively.)

To me this is confusing.  I thought "tracked" means whether an entity
such as FP and RA is tracked in SFrame generation for an architecture/ABI,
not whether it is saved.  Maybe use SFRAME_FRE_ELEM_LOC_SAVED and
SFRAME_FRE_ELEM_LOC_UNSAVED instead? Or SFRAME_FRE_ELEM_LOC_STACK and
SFRAME_FRE_ELEM_LOC_UNCHANGED?

> 
> Soon though, we will start to generate a new FDE type
> SFRAME_FDE_TYPE_FLEX, where:

Maybe ", where in addition to the above:"?

>   - the tracked entity may be saved in a temporary register
>   - the tracked entity may be saved at a "non-standard" location, e.g.,
>     not a simple CFA+offset based location
>   - and other cases
> 
> To effectively distinguish between the various states (necessary to
> track for flex FDEs), define three states to track the location of each
> tracked entity:
>   - SFRAME_FRE_ELEM_LOC_NONE: the entity is not tracked

"the entity is in its designated register"?  Or "designated location"
(to cater for AMD64 where the RA is at CFA+8 instead of a register).

Maybe SFRAME_FRE_ELEM_LOC_DESIGNATED instead of NONE?  Finding a good
terminology for this case drives me crazy.

>   - SFRAME_FRE_ELEM_LOC_REG: the entitiy is in a location based off a
>     register

Nit: s/entitiy/entity/

>   - SFRAME_FRE_ELEM_LOC_STACK: the entity is in a located based off the
>     CFA

Nit: s/located/location/

> 
> While at it, rather than asserting in sframe_xlate_do_offset (), reset
> the fp_reg state to SFRAME_FRE_REG_INVALID.  This is in preparation for
> upcoming flex FDE generation patches.
> 
> TBD:
>   - Add Co-Authored-By, Suggested-By Jens

As you like.

>   - Ideally the interfaces sframe_fre_set_ra_track,
>     sframe_fre_set_fp_track need an uplift, but we can address that when
>     time permits.
> 
> gas/
> 	* gen-sframe.c (sframe_xlate_do_offset): Reset other state.
> 	(sframe_xlate_do_same_value): Reset to SFRAME_FRE_ELEM_LOC_NONE.
> 	* gen-sframe.h (SFRAME_FRE_ELEM_LOC_REG): New definition.
> 	(SFRAME_FRE_ELEM_LOC_STACK): Likewise.
> 	(SFRAME_FRE_ELEM_LOC_NONE): Likewise.
> 
> ---
> [New in V1.  Not represent in RFC.]
> 
> [Changes in V2]
>   - Moved out some stubs resetting ra_reg, ra_deref_p, fp_deref_p
>     erroneously brought into this commit due a previous rebase.  These
>     fields are introduced only in a later commit, and hence this patch
>     would introduce build failures, making this not bisectable [Indu].
> [End of changes in V2]
> ---
>  gas/gen-sframe.c |  6 +++---
>  gas/gen-sframe.h | 10 ++++++++--
>  2 files changed, 11 insertions(+), 5 deletions(-)

Reviewed-by: Jens Remus <jremus@linux.ibm.com>

Regards,
Jens
-- 
Jens Remus
Linux on Z Development (D3303)
jremus@de.ibm.com / jremus@linux.ibm.com

IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Ehningen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/