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

[Rafael Auler via Phabricator via llvm-commits]

rafauler added a comment.

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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126933