Make lld to support win-xp
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Comment Actions
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.
Comment Actions
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.
Comment Actions
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.
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).
Comment Actions
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.
Comment Actions
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.)
Comment Actions
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.