[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

Wed Mar 31 16:22:08 PDT 2021

hvdijk added a comment.

In D52050#2662570 <https://reviews.llvm.org/D52050#2662570>, @glaubitz wrote:

> Since I am a big fan of consistency, I would rather leave it as is (4.6) and then bump to 10.2.0 in a follow-up commit.

You are right that including the bump in this commit would either force an inconsistency with basic_linux_tree, multilib_32bit_linux_tree, and multilib_64bit_linux_tree, or include more changes in here that are not related to x32. However, since we have been testing for x32 support against a pretend installation of GCC 4.6, and GCC 4.6 actually never supported x32 (initial support was added in GCC 4.7), leaving it at 4.6.0 means we are testing an impossible scenario. I am aware that we already were doing that before as well, but I do not think that changes much. Personally, I am not very happy with any of the options here.

I am also a fan of consistency, so to me the least bad option seems to be to update all four at the same time, provided this does not result in an excessively large diff. It looks large-ish but not too bad to me; I will include it in the next update so that we know what sort of size we are dealing with. If you and @MaskRay think it is too large I can easily take it out again.

> Debian actually has a /libx32 folder, but it contains the dynamic loader only which makes sense because the path to the dynamic loader is baked into the executable if I remember correctly.

Right, it has a /libx32 directory for exactly that reason. /libx32/ld-linux-x32.so.2 only exists as a compatibility symlink though, the dynamic loader is really stored in /lib/x86_64-linux-gnux32.

================
Comment at: clang/lib/Driver/ToolChains/Gnu.cpp:2110
+  static const char *const X32Triples[] = {"x86_64-linux-gnux32",
+                                           "x86_64-unknown-linux-gnux32",
+                                           "x86_64-pc-linux-gnux32"};
----------------
glaubitz wrote:
> hvdijk wrote:
> > MaskRay wrote:
> > > Personally I'd defer adding a triplet until it is proven to be used on a system.
> > > 
> > > This is not free, for every x86-64 user (even if they don't use multilib or x32), their clang driver runs need to stat the directory under lib/gcc or lib/gcc-cross.
> > For the first and last I know for a fact they are used as the GCC triple; /usr/lib/gcc/x86_64-linux-gnux32 and /usr/lib/gcc/x86_64-pc-linux-gnux32 definitely both exist in the wild. For the middle, x86_64-unknown-linux-gnux32, I do know for a fact this is used as a triple (it is the only valid x32 triple for Rust), but it is possible it is not used as the GCC triple anywhere, so unless someone speaks up that this is already in use somewhere, I will take that one out.
> Isn't Rust going to use `x86_64-unknown-linux-gnux32` when invoking the C++ compiler itself? I would prefer keeping it for consistency with x86_64 and to avoid issues with distributions that may use that triplet.
Thankfully, Rust does not require external triples to match its own strict naming rules. It does not accept `x86_64-linux-gnu` or `x86_64-pc-linux-gnu` as a valid targets either, only `x86_64-unknown-linux-gnu`, but it still works fine on systems where GCC does use any of the other triple names.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D52050