[PATCH v2 1/1] Fix IAT (Import Address Table) alignment on AArch64

[Jan Beulich]

On 05.05.2026 10:14, Evgeny Karpov wrote:
> On Fri, Apr 17, 2026, Jan Beulich wrote:
>> Hmm, so we're back to square 1 as far as the actual code change is concerned.
>> Further, I don't see how the link is related here. As you said yourself in a
>> reply on the v1 thread, there's no talk of alignment there. Neither your text
>> nor what is said there really addresses what I asked for in [1].
> 
> v3 will contain more generic changes to apply alignment to the IAT for PE32+.
> 
>> I also continue to be unhappy about the adhoc, hard-coded 3 in here. As
>> indicated, imo the function would better consult secdata_plain[], with that
>> in turn getting edited suitably (either at runtime, or by splitting the
>> "align" field into a pair of fields, one for PE32 and the other for PE32+).
>> The tool as a whole really wants to be self-consistent.
>  
> secdata*.align will be adjusted for PE32+.
> 
>> Yet further, as also indicated already, I don't follow why .idata$4 wouldn't
>> need (or at least want) treating the same. It also contains 8-byte elements
>> in PE32+.
> 
> .idata$4 emits the Import Lookup Table, which was not the purpose of this patch to resolve
> issues with relocating symbols from IAT when the function is called.
>  
>> Finally you still leave make_delay_head() entirely alone, when - as
>> indicated before as well - it clearly has the same issue.
> 
> v3 will contain changes in make_delay_head.

Btw, may I ask that you configure your mail program so that it properly
identifies replies? Just now I had "[PATCH v2 1/1] Fix IAT (Import
Address Table) alignment on AArch64" and "[PATCH v3 1/1] Fix IAT (Import
Address Table) alignment on AArch64" in my inbox. Clearly indicating
that the latter was an almost instant re-submission of the former (when
really the former was a reply on an old thread). In such an event I
would simply delete the obviously obsolete version, without even opening
it. It was only when looking at v3 0/1 that I recalled that your emails
lack the usual "Re:" prefix (or whichever translated version thereof).

Jan