This is an archive of the discontinued LLVM Phabricator instance.

Make lld to support win-xp
Needs ReviewPublic

Authored by gmh5225 on Dec 28 2021, 9:57 PM.

Details

Reviewers
mstorsjo
aganea
rnk
Group Reviewers
lld
Summary

Make lld to support win-xp

Diff Detail

Event Timeline

gmh5225 requested review of this revision.Dec 28 2021, 9:57 PM
gmh5225 created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptDec 28 2021, 9:57 PM
gmh5225 edited reviewers, added: MaskRay; removed: 01169957911, 01alchemist.Dec 29 2021, 9:54 PM
gmh5225 added a reviewer: lld.
MaskRay edited reviewers, added: mstorsjo, aganea, rnk; removed: 0x1eaf, 0b01, 0x59616e, MaskRay.Dec 30 2021, 12:45 AM
aganea added a subscriber: hans.Dec 31 2021, 10:56 AM

Apologies for deceiving, but I think we aren't and we shouldn't be supporting Windows XP in LLVM. The OS is deprecated since 2009 and Microsoft ended all support in 2014. We don't even support Windows 7 officially. I think most of Windows-specific bindings in llvm/lib/Support/Windows/ assume Windows 8+ APIs. @mstorsjo @hans @rnk do have a different opinion?

@gmh5225 Are you able to run ninja check-all in several configurations, with -DLLVM_ENABLE_PROJECTS="lld;llvm" and a combination of several of those? -DCMAKE_BUILD_TYPE=Release or -DCMAKE_BUILD_TYPE=Debug, -DLLVM_ENABLE_ASSERTIONS=ON or -DLLVM_ENABLE_ASSERTIONS=OFF, -DCMAKE_C_COMPILER=clang-cl.exe -DCMAKE_CXX_COMPILER=clang-cl.exe -DCMAKE_LINKER=lld-link.exe or -DCMAKE_C_COMPILER=cl.exe -DCMAKE_CXX_COMPILER=cl.exe -DCMAKE_LINKER=link.exe.

Apologies for deceiving, but I think we aren't and we shouldn't be supporting Windows XP in LLVM. The OS is deprecated since 2009 and Microsoft ended all support in 2014. We don't even support Windows 7 officially. I think most of Windows-specific bindings in llvm/lib/Support/Windows/ assume Windows 8+ APIs. @mstorsjo @hans @rnk do have a different opinion?

@gmh5225 Are you able to run ninja check-all in several configurations, with -DLLVM_ENABLE_PROJECTS="lld;llvm" and a combination of several of those? -DCMAKE_BUILD_TYPE=Release or -DCMAKE_BUILD_TYPE=Debug, -DLLVM_ENABLE_ASSERTIONS=ON or -DLLVM_ENABLE_ASSERTIONS=OFF, -DCMAKE_C_COMPILER=clang-cl.exe -DCMAKE_CXX_COMPILER=clang-cl.exe -DCMAKE_LINKER=lld-link.exe or -DCMAKE_C_COMPILER=cl.exe -DCMAKE_CXX_COMPILER=cl.exe -DCMAKE_LINKER=link.exe.

Thanks Reply. But some old projects need to be run on the Windows XP. And I want to make lld-link better.
I have not use ninja check-all. Buildbot is ok.

Apologies for deceiving, but I think we aren't and we shouldn't be supporting Windows XP in LLVM. The OS is deprecated since 2009 and Microsoft ended all support in 2014. We don't even support Windows 7 officially. I think most of Windows-specific bindings in llvm/lib/Support/Windows/ assume Windows 8+ APIs. @mstorsjo @hans @rnk do have a different opinion?

What OS the LLVM framework itself can run on, and what OS we can produce code *for* are two entirely different things. We don’t support running LLVM on such old versions (and some of the runtimes, e.g. libcxx, don’t officially support older versions either). But the tools should maybe be able to produce code for older OS though.

Thanks Reply. But some old projects need to be run on the Windows XP.

Those projects then need to explicitly set options like -subsystem:console,4.0.

I don’t think we shouldn’t lower our default target - there might be corner cases that don’t work as intended on older OSes (even if the common simple cases might work just fine).

mati865 added a subscriber: mati865.Jan 2 2022, 5:16 AM

There was similar differential recently: https://reviews.llvm.org/D112093

Quoting myself from that discussion:

I never had to dig into subsystem versions and what do the mean but looking at subsystem docs 4.0 stands for kernel mode drivers which looks wrong to me. They also specify 5.01 as 32-bit, 5.02 as 64-bit and 6.0 as being either 32-bit or 64-bit.

This means this change breaks compliance with Windows docs for x86_64 and AArch64 without valid reason.

There was similar differential recently: https://reviews.llvm.org/D112093

Quoting myself from that discussion:

I never had to dig into subsystem versions and what do the mean but looking at subsystem docs 4.0 stands for kernel mode drivers which looks wrong to me. They also specify 5.01 as 32-bit, 5.02 as 64-bit and 6.0 as being either 32-bit or 64-bit.

That's not how I interpret it. It's not that 4.0 stands for kernel version. In most cases (for the windows/console subsystem), subsystem version is a synonym for OS version (and when set via the -subsystem option to link.exe/lld-link, it sets both subsystem and OS version). And that page probably has been updated when purging documentation/support for older OS versions. When targeting Win9x and NT4, you'd have subsystem/OS version 4.0, when targeting Win2k/XP as baseline, it'd be 5.0, and requiring Vista if it's set to 6.0.

This means this change breaks compliance with Windows docs for x86_64 and AArch64 without valid reason.

Yes, that's probably true - I wouldn't be surprised if ARM binaries declaring a minimum version of 4.0/5.0 wouldn't be launched at all. (Similarly, Windows refuses to load ARM binaries unless the dynamicbase flag is set.)

rnk added a comment.Jan 4 2022, 4:28 PM

Right, my memory of D112093 is that users are free to set a lower subsystem version if they want. @mstorsjo said:

Overall, many things assume Windows 7 these days, so I don't think it's an entirely unreasonable default - you can always set a lower target if you want to, by passing e.g. --major-os-version 4 to the linker. I don't think the default of the main COFF linker should be lowered.

The change to the canned XML seems pretty minor, right? We could probably take that part, and drop the subsystem version changes.