This is an archive of the discontinued LLVM Phabricator instance.

[clang][Driver] Correct runtime path for Arm hard float targets
AbandonedPublic

Authored by DavidSpickett on Sep 21 2021, 2:54 AM.

Details

Reviewers
MaskRay
Summary

On armv8l and arm (armv7) the architecture in the library
path will be "armhf" if we have hard float enabled.

This fixes failures like:
https://lab.llvm.org/buildbot/#/builders/178/builds/591

Where we can't find the libraries since
https://reviews.llvm.org/D107799 landed.

Before:
$ ./bin/clang --target=armv8l-unknown-linux-gnueabihf -print-runtime-dir
<...>/build-llvm-arm/lib/clang/14.0.0/lib/linux

After:
$ ./bin/clang --target=armv8l-unknown-linux-gnueabihf -print-runtime-dir
<...>/build-llvm-arm/lib/clang/14.0.0/lib/armhf-unknown-linux-gnueabihf

Diff Detail

Event Timeline

DavidSpickett created this revision.Sep 21 2021, 2:54 AM
DavidSpickett requested review of this revision.Sep 21 2021, 2:54 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 21 2021, 2:54 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript

getRuntimePath seems like the place to fix it given that https://reviews.llvm.org/D50547 calls it. This fixes the tests but I'm not sure if there's other places to consider.

I should probably *add* a test somewhere for this too.

Added a test.

I have not checked what adding an -mfloat-abi that doesn't
match the ABI part of the triple does because then
we'd need to modify the ABI part of the triple as well.

Which might be the correct thing to do in the end but I'll wait
and see what people think.

MaskRay added a comment.EditedSep 21 2021, 10:49 AM

Do you know why --target=armv8l-unknown-linux-gnueabihf picks armhf-unknown-linux-gnueabihf instead of armv8l-unknown-linux-gnueabihf?
(For new tests, prefer --target= to -target ; space separated driver options are not the convention.)

The direction the Clang driver should move to is less magic. See D109727.
If you can take a look whether the various ARM*Triples in Gnu.cpp around line 2090 can be cleaned up (removed), that would be great!

clang/lib/Driver/ToolChain.cpp
492

Add a comment similar to

// --target=armv8l-unknown-linux-gnueabi prefers to change the machine part to arm{,hf}. The os part may change to gnueabi{,hf}.

MaskRay added inline comments.Sep 21 2021, 10:51 AM
clang/test/Driver/arm-float-abi-runtime-path.c
7

Having one of armv7/armv8l is sufficient.

We should use the fewest RUN lines to ensure coverage. As is, spawning 8 clang processes is too expensive.

14

Having one of armv7/armv8l is sufficient.

phosek added a subscriber: phosek.Sep 21 2021, 11:01 AM

Do you know why --target=armv8l-unknown-linux-gnueabihf picks armhf-unknown-linux-gnueabihf instead of armv8l-unknown-linux-gnueabihf?
(For new tests, prefer --target= to -target ; space separated driver options are not the convention.)

The direction the Clang driver should move to is less magic. See D109727

I agree with @MaskRay, we discussed this when updating the Clang multiarch layout and the decision was to use normalized LLVM triples to avoid additional translations as is done in this change.

It also seems like armhf-unknown-linux-gnueabihf duplicates the hf bit (there's both armhf and gnueabihf) which seems unnecessary.

So would you expect to see libraries in lib/clang/14.0.0/lib/armv8l-unknown-linux-gnueabihf and not change clang's logic?

The output dir is worked out in cmake by get_compiler_rt_output_dir which calls get_compiler_rt_target which takes the arch given and adds it to the suffix of the triple. So it adds "armhf" to "-unknown-linux-gnueabihf". (which is why the "hf" is duplicated)

A few places look for "armhf" specifically as the arch, so it's not as easy as just not converting "armv8l" into that. But if we can confirm what the goal is here then I can find out how to properly handle those.

You can just bodge get_compiler_rt_target to just use the target triple but of course that breaks any build for multiple targets. If I'm reading test_targets correctly, it builds a list of architectures to build as opposed to finding the first working one.

So would you expect to see libraries in lib/clang/14.0.0/lib/armv8l-unknown-linux-gnueabihf and not change clang's logic?

I'd hope that it works this way (armv8l-*) :)

The output dir is worked out in cmake by get_compiler_rt_output_dir which calls get_compiler_rt_target which takes the arch given and adds it to the suffix of the triple. So it adds "armhf" to "-unknown-linux-gnueabihf". (which is why the "hf" is duplicated)

A few places look for "armhf" specifically as the arch, so it's not as easy as just not converting "armv8l" into that. But if we can confirm what the goal is here then I can find out how to properly handle those.

I took a glance at get_compiler_rt_target... It is complex. If you can figure it out, that will be great!

You can just bodge get_compiler_rt_target to just use the target triple but of course that breaks any build for multiple targets. If I'm reading test_targets correctly, it builds a list of architectures to build as opposed to finding the first working one.

I'd hope that it works this way (armv8l-*) :)

Cool I'm going to work with that goal in mind then.

I've turned it off by default for 32 bit Arm linux until it's made compatible: https://reviews.llvm.org/rG3c65d54ec3d2

DavidSpickett planned changes to this revision.Oct 14 2021, 8:25 AM
DavidSpickett abandoned this revision.Feb 10 2022, 2:51 AM