[PATCH v4 2/7] Define unwinding and SEH data structures for aarch64

[Evgeny Karpov]

On Fri, Oct 10, 2025 Jan Beulich wrote:
>> +typedef struct seh_aarch64_unwind_code
>> +{
>> +  uint32_t value;
>> +  seh_aarch64_unwind_types type;
>> +} seh_aarch64_unwind_code;
> 
> I can't find any match for this in the spec above. If I'm overlooking it,
> then I don't think you can use seh_aarch64_unwind_types here. If this is
> an internal structure, then I question the use of uint32_t (should perhaps
> be unsigned int instead). Plus the placement of the struct is then also
> misleading.

Only the value is used for emitting. The type is used for obtaining extra information,
such as size, and so on. The value is limited to 4 bytes. It might be changed to unsigned
if that brings more clarity. seh_aarch64_unwind_code is used by seh_aarch64_context.

>> +typedef struct seh_aarch64_pdata
>> +{
>> +  unsigned int func_start_rva;
> 
> Kind of the inverse question here: If this is (as per its placement)
> representing something from the spec, then why unsigned int and not
> uint32_t?

A good question. This structure is no longer needed.

>> +  uintptr_t epilogue_start_offset;
>> +  uintptr_t epilogue_end_offset;
> 
> Same question here towards uintptr_t, the size of which is a host property,
> not a target one.

This is an internal structure and is used by seh_aarch64_context.

>> +} seh_aarch64_epilogue_scope;
>> +
>> +typedef struct seh_aarch64_func_fragment
>> +{
>> +  uintptr_t offset;
>> +  symbolS *xdata_addr;
>> +  struct seh_aarch64_func_fragment *next;
>> +} seh_aarch64_func_fragment;
>
> This, otoh, is clearly an internal structure. Imo there it would be better
> to use bfd_vma (in favor of uintptr_t), for then being tied to the target,
> not the host.

uintptr_t will be replaced with bfd_vma.

>> +/* aarch64 unwind code structs.  */
> 
> Why "structs" when ...

It makes sense to rename it to "aarch64 unwind code prefixes".

Regards,
Evgeny