Page MenuHomePhabricator

[Driver] Drop $DEFAULT_TRIPLE-$name as a fallback program name
ClosedPublic

Authored by MaskRay on Apr 6 2021, 3:34 PM.

Details

Summary

D13340 introduced this behavior which is not needed even for mips.
This was raised on https://lists.llvm.org/pipermail/cfe-dev/2020-May/065437.html
but no action was taken.

This was raised again in https://lists.llvm.org/pipermail/cfe-dev/2021-April/067974.html
"The LLVM host/target TRIPLE padding drama on Debian"
as it caused confusion. This patch drops the behavior.

Diff Detail

Event Timeline

MaskRay created this revision.Apr 6 2021, 3:34 PM
MaskRay requested review of this revision.Apr 6 2021, 3:34 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 6 2021, 3:34 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript
glaubitz added a subscriber: jrtc27.Apr 6 2021, 4:10 PM

To understand better, we will be fixing a bug from 2015, correct?

atanasyan accepted this revision.Apr 7 2021, 1:30 AM

LGTM

AFAIK the MIPS LLVM-based toolchain mentioned in D13340 have not been implemented.

This revision is now accepted and ready to land.Apr 7 2021, 1:30 AM

I believe adding the default triple is causing the wrong linker to be selected for me when compiling with -m32, so I'd be happy for this code to be removed.

nickdesaulniers accepted this revision.Apr 7 2021, 10:37 AM

I don't foresee this affecting Linux kernel builds.

Adding Dan as an FYI. While this doesn't impact Android platform or regular NDK users, I suppose that someone could have some esoteric build rules that are relying on this, but they should probably be more explicit about what they're running in those cases anyways.

MaskRay added a comment.EditedApr 7 2021, 11:24 AM

To understand better, we will be fixing a bug from 2015, correct?

Yes.

I believe adding the default triple is causing the wrong linker to be selected for me when compiling with -m32, so I'd be happy for this code to be removed.

Yes...

Adding Dan as an FYI. While this doesn't impact Android platform or regular NDK users, I suppose that someone could have some esoteric build rules that are relying on this, but they should probably be more explicit about what they're running in those cases anyways.

The 2015 behavior is that a --target=aarch64-linux-gnu cross compile may pick up x86_64-unknown-linux-gnu-{as,ld,gcc}. First most Linux programs should be named x86_64-linux-gnu-* (x86_64-pc-linux-gnu-* is more common but one needs to configure llvm-project with LLVM_DEFAULT_TARGET_TRIPLE=x86_64-pc-linux-gnu, the default is unknown).
Second x86_64-unknown-linux-gnu-{as,ld,gcc}, even if exists, is unlikely to handle aarch64-linux-gnu builds... So the case should be very rare.

MaskRay edited the summary of this revision. (Show Details)Apr 7 2021, 9:00 PM