[PATCH 2/3] gas: Use SFrame header and FDE field sizes when generating .sframe

[Jens Remus]

On 25.02.2025 01:43, Indu Bhagat wrote:
> On 2/21/25 8:56 AM, Jens Remus wrote:
>> The use of SFRAME_RELOC_SIZE in generation of SFrame stack trace
>> information from CFI directives erroneously suggested that this could
>> be used to configure a different relocation size.  But in practice it
>> is tied to the SFrame field sizes it is used for and therefore cannot
>> be changed.

...

> Right. Your patch is correct in that it identifies following issues:
>    - #1. SFRAME_RELOC_SIZE may be mistakenly deemed configurable.
>    - #2. Tieing fields like sfh_fre_len, or other sub-section offsets (sfh_fdeoff, sfh_freoff) to SFRAME_RELOC_SIZE is incorrect.
> 
> However, IMO having each individual emit_expr () use the sizeof_member () gives the impression that each affected member, especially those in category #2, can evolve independently (as the format evolves). This is not the case.

My goal was to tie each emit_expr() to the size of the field as it is
defined in the respective struct that defines the SFrame V2 data format.

> So perhaps it is clearer if we identify the two distinct members here and add them to the struct sframe_version_ops:
>    - unsigned char addr_size
>    - unsigned char subsection_offset_size (to avoid confusion with the SFrame stack offsets, if any)
> 
> Then initialize them to 4 in sframe_set_version () for SFRAME_VERSION_2.

I dislike that it again uses some other value as size of the fields.
Whether that is a define or struct sframe_version_ops variable does not
matter much.  It would potentially require to introduce asserts that
addr_size and subsection_offset_size match the size of the fields they
are then used for.

> It still needs to be worked out how supporting FDE func start address
> of size 8 bytes will look like for SFRAME_VERSION_3, but I think adding
> these to the sframe_version_ops will be clearer.

Couldn't it be that the whole FDE and FRE layout changes considerably
in SFrame V3, so that output_sframe_funcdesc() et. al would require to
be versioned?

Do you plan to support output of SFrame V2 and V3 in parallel?

Thanks and regards,
Jens
-- 
Jens Remus
Linux on Z Development (D3303)
+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/