[PATCH] winnt.h: Fix MSVC variants of InterlockedIncrement16 and InterlockedDecrement16.

[Martin Storsjö]

Hi,

On Tue, 16 Feb 2021, Jacek Caban wrote:

> On 15.02.2021 12:58, Martin Storsjö wrote:
>> On Wed, 10 Feb 2021, Martin Storsjö wrote:
>> 
>>> On Wed, 10 Feb 2021, Jacek Caban wrote:
>>> 
>>>> I had another look at it and I sent the part that replaces use of llvm-ar 
>>>> and llvm-ranlib with lld-link /lib. However, I couldn't get importlibs 
>>>> using lld-link -implib right. I tried MSVC, suspecting that something is 
>>>> wrong with lld-link, but I found that what I was trying to do is not 
>>>> supported by link.exe. -implib option is really meant for an addition to 
>>>> linker, not for importlib-only execution.
>>> 
>>> It does seem to work for me, e.g. like this:
>>> 
>>> link.exe -lib -machine:arm64 -def:test.def -out:test.lib
>>> 
>>> However lld-link doesn't implement that combination, so you're right that 
>>> llvm-dlltool is the one we have to use for now. I guess I should look into 
>>> implementing that option combination at some point though.
>> 
>> Actually, lld-link has implemented a very similar variant:
>> 
>> lld-link -machine:arm64 -def:test.def -implib:test.lib
>> 
>> Which does the equivalent of
>> 
>> link.exe -lib -machine:arm64 -def:test.def -out:test.lib
>> 
>> This hasn't been implemented in llvm-lib though (which is what you get when 
>> calling lld-link /lib); it'd require moving a couple functions out from lld 
>> into the lower level libraries/interfaces that are shared with llvm-lib.
>> 
>> If you're ok with deviating from the strict MSVC interfaces, then just 
>> "lld-link -machine: -def: -implib:" does that though. 
>
>
> I tried that and I couldn't get it to work. That's what this patch does:
>
> https://source.winehq.org/patches/data/198665
>
> x86 build with that patch has broken imports because it includes stdcall 
> decorations in import table. I couldn't make it stop doing that. With 
> additional '=undecoredsymbol' in .def files I could strip leading underscore, 
> but import entries still contained '@argsize' part.

Ah, right, hmm.

I think that link.exe style linkers requires you to actually do linking 
from object files, to be able to deduce those aspects (that symbols have 
decoration but dll export names don't), and it can't describe those 
nuances properly just by the def file. Creating the def files with 
*dlltool fixes that as long as the -k option is used though.

So yeah, for i386, a dlltool that supports the -k option is pretty much 
required, I think.

// Martin