Re: [PATCH v2 1/1] aarch64: mingw: Auto-import implementation

On Fri, 31 Jul 2026, Martin Storsj� wrote:
> >  b init_dyn_v
> >  bl init_dyn_v
> > 
> > init_dyn_v and dyn_v are undefined at compile time and are getting resolved
> > during linking with a dynamic library to the IAT (import address table).
> > 
> > In case of b or bl, it can be done by using a jump table
> 
> I think the term "jump table" usually refers to something entirely
> different? What you have here normally is just called a thunk.
 
The description will be updated.

> > init_dyn_v:
> >  adrp	x16, __imp_init_dyn_v
> >  add	x16, x16, :lo12:__imp_init_dyn_v
> >  ldr	x16, [x16]
> 
> These two instructions can be just one single "ldr x16, [x16,
> :lo12:__imp_init_dyn_v]"

This stub is reused and might be optimized as a separate patch.
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=ld/pe-dll.c;h=f43bd14896ea78c8cab1523ff7c8fb4de029ea6e;hb=refs/heads/master#l2320
 
> > 
> > __imp_dyn_v_10_8:
> >   adrp	x0, __imp_dyn_v
> >   ldr	x0, [x0, :lo12:__imp_dyn_v]
> >   add	x0, x0, offset_4k, lsl #12
> >   b	__fu1_dyn_v + 0x4
> 
> Thanks for the clear examples of what this does!
> 
> I think this may work - although on first look, it feels like it's adding a
> fair amount of overhead.
> 
> On the other hand - the overhead it adds is only paid for the cases where
> the autoimported data symbol actually is referenced; code that doesn't
> autoimport any data symbols won't have any extra overhead at all.
> 
> 
> For reference - what we did in LLVM for this was to mirror what already was
> being done for x86_64: On x86_64, GCC (and also LLVM) generates indirection
> through a .refptr stub - which essentially works like a GOT entry. Whenever
> the compiler references a symbol which it can't be sure is in the same
> module, instead of doing
> 
>     adrp x0, symbol+offset
>     add x0, x0, :lo12:symbol+offset
> 
> it generates
> 
>     adrp x0 .refptr.symbol
>     ldr x0, [x0, :lo12:.refptr.symbol]
> 
>     .section .rdata$.refptr.symbol,"dr",discard,.refptr.symbol
>     .globl .refptr.symbol
> .refptr.symbol:
>     .xword symbol
> 
> (For cases where the intended code was adrp+ldr to begin with, it becomes
> one extra ldr.)
> 
> The generated code is mostly efficient, although there can be one extra ldr
> per access, and you get the binary size overhead of all the extra .refptr
> elements for all the symbols that weren't autoimported.
> 
> Given the preexisting case of GCC doing this for x86_64, I would have
> expected that the least surprising way of dealing with it would be to do the
> same for aarch64.
> 
> But anyway, I see the pros and cons of your approach, as it adds zero
> overhead for the non-autoimported cases.

Unconditional branching in this solution should not significantly impact
execution. In terms of overhead, this handling will be applied very rarely on
average, with almost zero overhead.

Regards,
Evgeny