[PATCH v4 3/7] Adjust x64 SEH implementation for AArch64

[Evgeny Karpov]

On Mon, Feb 02, 2026, Jan Beulich wrote:
> > Splitting SEH implementations for x64 and aarch64 into two separate source files
> > should look better. Also it should prevent regressions in x64 implementation
> > because the x64 files will be only renamed.
> > Here is a proposal for the file names:
> > obj-coff-seh.h (common)
> > obj-coff-seh-i386.h / obj-coff-seh-i386.c 
> > and obj-coff-seh-aarch64.h / obj-coff-seh-aarch64.c
> 
> The current file isn't x86-only afaics, but also contains code to support
> e.g. Arm and MIPS.

Thanks for mentioning this. Then it looks like obj-coff-seh.h / obj-coff-seh.c 
should stay unchanged, and obj-coff-seh-aarch64.h / obj-coff-seh-aarch64.c will
be created for aarch64 SEH implementation.

> >>> @@ -366,10 +450,21 @@ obj_coff_seh_handler (int what ATTRIBUTE_UNUSED)
> >>>    seh_ctx_cur->handler_data.X_add_number = 0;
> >>>    seh_ctx_cur->handler_flags = 0;
> >>>
> >>> +#if defined (COFFAARCH64)
> >>> +  seh_ctx_cur->aarch64_ctx.xdata_header.x = 1;
> >>
> >> Why unconditionally 1?
> > 
> > It indicates the presence of exception data, which is always emitted.
> 
> Why's there a flag if this data is always emitted?

xdata might not have exception data as an option, however in the current
aarch64 implementation it is always emitted.

> >>> @@ -505,10 +731,27 @@ obj_coff_seh_endprologue (int what ATTRIBUTE_UNUSED)
> >>>  void
> >>>  obj_coff_seh_do_final (void)
> >>>  {
> >>> -  if (seh_ctx_cur != NULL)
> >>> +  if (in_seh_proc)
> >>>      as_bad (_("open SEH entry at end of file (missing .seh_endproc)"));
> >>> +
> >>> +#if defined (COFFAARCH64)
> >>> +
> >>> +  if (!seh_ctx_root)
> >>> +    return;
> >>> +
> >>> +  struct seh_context *seh_ctx = seh_ctx_root;
> >>> +  while (seh_ctx)
> >>> +  {
> >>> +    emit_pdata_xdata_records (seh_ctx);
> >>> +    struct seh_context *next = seh_ctx->next;
> >>> +    free_seh_ctx (seh_ctx);
> >>> +    seh_ctx = next;
> >>> +  }
> >>> +  seh_ctx_root = NULL;
> >>
> >> Move this up to prevent the value becoming a dangling pointer during the 1st
> >> loop iteration?
> > 
> > Yes, as an option, it can be moved. Anyway, multithreading is not supported
> > by this implementation.
> 
> I never thought of multi-threading here. Any function you call can, in principle,
> look at and use the pointer.

It looks like it is a reference to free_seh_ctx. Ok.

Regards,
Evgeny