On Mon Jun 26 20:46:45 2023 +0000, Martin Storsjö wrote:
maybe that's just a bug in llvm-mingw, I'm not sure it needs them and
I don't think GCC generates them for i386. I'm not usually using it. Just FTR, the fact that Clang produces .refptr stubs on i686 isn't an accident - it's quite intentional. (I guess it'd be good to document the rationale somewhere...) The .refptr stubs are added for three reasons:
- To extend the range of the symbol references, to avoid issues if the
referenced DLL is loaded too far away. (This is only an issue on 64 bit platforms.) 2. To avoid runtime pseudo relocations in the text section. When the pseudo relocations are fixed up at startup, the relocation fixing code has to make parts of the section writable (in practice, it changes the whole secion). Making a section both executable and writable at the same time is generally not good, and it's not allowed at all in e.g. UWP mode. By using refptr stubs, there shouldn't be any pseudo relocations in the text sections. 3. The pseudo relocations can only update offsets in general 1/2/4/8 byte addresses (absolute or relative). On x86, the relevant instructions that reference a symbol consists of a few leading instruction bytes, followed by a plain raw 32 bit address (either absolute or RIP relative). On arm however, such addresses aren't encoded as a plain 32 bit address, but the address is scattered throughout the isntruction bits. See e.g. the handling of IMAGE_REL_BASED_THUMB_MOV32 in LdrProcessRelocationBlock. Therefore, the runtime pseudo relocation mechanism simply can't handle relocations in code on arm architectures. So for these reasons, Clang produces .refptr stubs by default on all architectures. On i686, only issue 2 is relevant though. Whenever such references actually are autoimported, lld has got a trick to merge the .refptr stub into the actual IAT entry, avoiding the whole runtime pseudo relocation altogether. But if it isn't autoimported, then it does indeed generate unnecessary indirection. So it would indeed be good to be able to opt out of it; I guess I should try to pick that patch up again.
For Wine itself, we don't use runtime pseudo relocs (we don't even support them in crt) and it would be indeed good to have a way to pass that information to the compiler. I can see that there were concerns about the interface, maybe Clang could treat `-fvisibility=hidden` on mingw targets as a way to opt-out, following the logic that if a symbol is hidden, we don't expect it to be (auto)imported.