This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Fix running tests when LLVM target triple is different from host
Needs RevisionPublic

Authored by alvinhochun on Sep 27 2022, 10:38 AM.

Details

Summary

This passes the host triple to the lldbsuite test builder used in API
tests and the build helper used in Shell tests, so that Clang can use
the correct host triple when LLVM was configured with a default target
triple different from the host triple.

Diff Detail

Event Timeline

alvinhochun created this revision.Sep 27 2022, 10:38 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 27 2022, 10:38 AM
alvinhochun requested review of this revision.Sep 27 2022, 10:38 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 27 2022, 10:38 AM
JDevlieghere requested changes to this revision.Sep 27 2022, 11:15 AM

Supporting builds with different host and target triples makes sense. However, I have a few concerns about the current patch:

  • I wouldn't cal it the "host triple". The API tests (dotest.py) support running the test suite for a different platform/architecture. Take a look at the Darwin builder and you'll see a bunch of support for that.
  • How does this interact with the -arch flag? When the host and target triple differ, which part of the triple is different? In theory it can be any part, but maybe your use case could be covered by setting the --arch flag?
  • This doesn't update getTriple in builder.py which is necessary for some of the decorators to work (in particular the ones that invoke the compiler to see if something is supported).
This revision now requires changes to proceed.Sep 27 2022, 11:15 AM

Thanks for the review.

Supporting builds with different host and target triples makes sense. However, I have a few concerns about the current patch:

  • I wouldn't cal it the "host triple". The API tests (dotest.py) support running the test suite for a different platform/architecture. Take a look at the Darwin builder and you'll see a bunch of support for that.

How about calling it "clang triple"?

  • How does this interact with the -arch flag? When the host and target triple differ, which part of the triple is different? In theory it can be any part, but maybe your use case could be covered by setting the --arch flag?

If I run Clang with --target=x86_64-linux-gnu -m32 then it automatically targets i386-linux-gnu, so I suppose -arch should override the arch part of the target, which is correct. DarwinBuilder::getArchCFlagson the other hand has a different handling which generates a -target option from arch and other Apple-specific details without considering the new host-triple flag (or whatever we end up calling it), so it should behave the same as before this change.

For me, my Linux native build has the default target triple configured to x86_64-w64-windows-gnu, and linking of lldb tests fail due to missing mingw-w64 libraries. (Even if they do link the tests probably won't work anyway.) The Shell tests that use the %clang_host lit substitution work because they include the host --target flag, so I thought the tests using the build scripts should do the same.

  • This doesn't update getTriple in builder.py which is necessary for some of the decorators to work (in particular the ones that invoke the compiler to see if something is supported).

I see, I will change this too.