[PATCH] D126933: [BOLT] Restrict execution of tests that fail on Windows

Amir Ayupov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jul 11 15:10:18 PDT 2022


Amir accepted this revision.
Amir added a comment.
This revision is now accepted and ready to land.

In D126933#3557106 <https://reviews.llvm.org/D126933#3557106>, @rafauler wrote:

> In D126933#3555080 <https://reviews.llvm.org/D126933#3555080>, @Amir wrote:
>
>> I've recently added some magic to pass linux target triple to cflags in bolt/test/lit.local.cfg:
>>
>>   host_linux_triple = config.target_triple.split('-')[0]+'-linux'
>>   common_linker_flags = '-fuse-ld=lld -Wl,--unresolved-symbols=ignore-all'
>>   flags = f'--target={host_linux_triple} {common_linker_flags}'
>>
>> This would take the arch from target triple (x86_64 or aarch64) and append `-linux`. I didn't test it on Windows but it works on macOS. Therefore I'm reluctant to add `system-linux` to these tests that would restrict them to linux.
>>
>> Can you please share what's passed as cflags on windows? Let's try to fix it. Our tests don't depend on system headers, so there's a good chance they would work even on windows.
>
> Sorry, you're right, I should at least update that comment, the triple is indeed being passed correctly. But the driver gets confused as it tries to locate libc stuff in an environment that lacks them:
>
>   $ "c:\users\rafael\llvm\build\minsizerel\bin\clang.exe" "--target=x86_64-linux" "-fuse-ld=lld" "-Wl,--unresolved-symbols=ignore-all" "-fPIC" "-shared" "C:\Users\Rafael\llvm\llvm-project\bolt\test\R_ABS.pic.lld.cpp" "-o" "C:\Users\Rafael\llvm\build\tools\bolt\test\Output\R_ABS.pic.lld.cpp.tmp.so" "-Wl,-q" "-fuse-ld=lld"
>   # command stderr:
>   ld.lld: error: cannot open crti.o: no such file or directory
>   ld.lld: error: cannot open crtbeginS.o: no such file or directory
>   ld.lld: error: unable to find library -lgcc
>   ld.lld: error: unable to find library -lgcc_s
>   ld.lld: error: unable to find library -lc
>   ld.lld: error: unable to find library -lgcc
>   ld.lld: error: unable to find library -lgcc_s
>   ld.lld: error: cannot open crtendS.o: no such file or directory
>   ld.lld: error: cannot open crtn.o: no such file or directory
>   clang: error: linker command failed with exit code 1 (use -v to see invocation)
>
> I imagine the driver is trying to look for stuff in /lib, /lib64 etc. but we are on windows, so it is never going to find these libc dependencies, even if it is aware of the target triple.
>
> We would need to use some sort of -ffreestanding in order to be able to be truly independent of the system and avoid pulling in surprises into the final binary. I didn't bother modifying the tests as I didn't want to spend time trying to figure out if -ffreestanding would be creating an adequate test case. But if its working on MacOS, maybe we need to investigate where it is finding the object files with start symbols, because that's curious.

Sorry for a long delay.
Tests are failing to link just the same. I agree it makes sense to require system-linux.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126933/new/

https://reviews.llvm.org/D126933



More information about the llvm-commits mailing list