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

[Indu Bhagat]

On 1/7/26 5:38 AM, Jens Remus wrote:
> 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)
> 

OK.

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

Yes this is true.  This is how I have been using "tracked" too.  Sorry 
for overloading the word.

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?
> 

I think its best to remove that line from commit log altogether as it 
can be source of confusion.

>>
>> Soon though, we will start to generate a new FDE type
>> SFRAME_FDE_TYPE_FLEX, where:
> 
> Maybe ", where in addition to the above:"?
> 

OK.

>>    - 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/
> 

Done.

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