This is an archive of the discontinued LLVM Phabricator instance.

Allow the discovery of Android NDK's triple-prefixed binaries.
AcceptedPublic

Authored by brianpl on Dec 23 2019, 2:39 PM.

Details

Summary

Currently, tool discovery checks for a tool with its target triple as a
prefix. Unfortunately, the triple it uses is canonicalized, and may
contain the Android platform numbers as a suffix. This prevents matching
of the binaries in the LLVM bin directory of the Android NDK.

This CL adds checks during discovery that will match the canonical
Android NDK triples. The matcher will work with vendor "unknown", and at
any level platform.

Event Timeline

brianpl created this revision.Dec 23 2019, 2:39 PM
Herald added a project: Restricted Project. · View Herald TranscriptDec 23 2019, 2:39 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript
brianpl updated this revision to Diff 235182.Dec 23 2019, 2:41 PM

Fix a typo.

Harbormaster completed remote builds in B42906: Diff 235182.
danalbert accepted this revision.Jan 6 2020, 9:41 AM

Just to clarify, this is needed for the triple-prefixed tools, but the triple-specific directory worked fine before this patch? If I'm understanding that correctly then LGTM, otherwise I'm confused as to why I haven't seen this problem before.

This revision is now accepted and ready to land.Jan 6 2020, 9:41 AM

Just to clarify, this is needed for the triple-prefixed tools, but the triple-specific directory worked fine before this patch? If I'm understanding that correctly then LGTM, otherwise I'm confused as to why I haven't seen this problem before.

Yes, that's right. Without the patch, Clang will overlook the triple-prefixed tools, but it will correctly find tools in the triple-specific directory either way.

jyknight added inline comments.Jan 7 2020, 2:36 PM
clang/lib/Driver/Driver.cpp
4696

Adding the hardcoding here seems unfortunate. We have some code like this already in other places. It may be better to reuse the same logic. In particular, I'd expect we want to find program-prefixed names the same way as we did paths.

That seems to be done here https://github.com/llvm/llvm-project/blob/b6598bcf4b81ed8fb66a7c576a81e422750b9329/clang/lib/Driver/ToolChains/Linux.cpp#L236

While this function doesn't currently provide for a list of prefixes to be input, adding such a mechanism, and then having the code referenced above above add the prefix to the list, would seem better.

brianpl updated this revision to Diff 237691.Jan 13 2020, 8:27 AM

Since this change is not android-only, please update change description, and update some non-android tests.

E.g. maybe the tests in clang/test/Driver/linux-ld.c for ubuntu_14.04_multiarch_tree should check the path at which ld is found. While the existing Inputs/ubuntu_14.04_multiarch_tree doesn't have any "ld" files populated, and the tests aren't checking for ld's path at all, it would be reasonable to add such files and then check the result.

This is what the layout of the "ld" files look like in current ubuntu versions on x86_64. It seems that it was almost the same back in 2014 -- except the triple-less names were the primary file, and the others linked to them. That's not really relevant to the test, anyways, just the filenames existing and being executable.

lrwxrwxrwx  /usr/bin/ld.bfd -> x86_64-linux-gnu-ld.bfd
lrwxrwxrwx  /usr/bin/ld.gold -> x86_64-linux-gnu-ld.gold
lrwxrwxrwx  /usr/bin/ld -> x86_64-linux-gnu-ld
-rwxr-xr-x  /usr/bin/x86_64-linux-gnu-ld.bfd
-rwxr-xr-x  /usr/bin/x86_64-linux-gnu-ld.gold
-rwxr-xr-x  /usr/bin/x86_64-linux-gnu-ld -> x86_64-linux-gnu-ld.bfd
-rwxr-xr-x  /usr/bin/powerpc64le-linux-gnu-ld.bfd
-rwxr-xr-x  /usr/bin/powerpc64le-linux-gnu-ld.gold
-rwxr-xr-x  /usr/bin/powerpc64le-linux-gnu-ld -> powerpc64le-linux-gnu-ld.bfd

Before this clang patch, we would've defaulted to /usr/bin/ld unless the target string was specified exactly as "x86_64-linux-gnu" or "powerpc64le-linux-gnu". Afterwards, we can also chose those tools for any other triple which we can detect as matching those gcc installation triples.

This would even have the useful effect of allowing an invocation like "clang -target powerpc64le-unknown-linux-gnu" to work, which it doesn't do currently -- because it defaults to /usr/bin/ld, which is an x86_64 linker.

clang/lib/Driver/ToolChains/Gnu.cpp
2578 ↗(On Diff #237691)

I suspect this doesn't actually work here, since GCCInstallation.init() hasn't yet been called. But you have the same in Linux.cpp, after the init() call, which seems better.

clang/lib/Driver/ToolChains/Linux.cpp
242 ↗(On Diff #237691)

Probably should check that GCCInstallation.getTriple() != Triple before adding, in order to avoid duplicating entries in the search-list.

clang/test/Driver/android-triple-version.c
2

This seems like too many test-cases. It doesn't seem to me that they're actually adding any meaningful coverage, after the first 3?

7

You shouldn't edit files in the Inputs tree (or add/remove files there either). If this script stops, it may be left in an edited state, which would be bad. Also, sometimes it might be read-only.

Another way to achieve this test goal may be with -fuse-ld=prefixtest, and then create bin/$triple-ld.prefixtest, but not $triple/bin/ld.prefixtest