Page MenuHomePhabricator

[Driver] Fix incorrect GNU triplet for PowerPC on SUSE Linux
ClosedPublic

Authored by aaronpuchert on Dec 5 2018, 7:25 AM.

Details

Summary

On SUSE distributions for 32-bit PowerPC, gcc is configured
as a 64-bit compiler using the GNU triplet "powerpc64-suse-linux",
but invoked with "-m32" by default. Thus, the correct GNU triplet
for 32-bit PowerPC SUSE distributions is "powerpc64-suse-linux"
and not "powerpc-suse-linux".

Diff Detail

Event Timeline

glaubitz created this revision.Dec 5 2018, 7:25 AM
jrtc27 requested changes to this revision.Dec 5 2018, 7:41 AM

Yes, this is a stupid situation to be in, but 32-bit PowerPC on SUSE really does use /usr/lib/gcc/powerpc64-suse-linux:

root@redpanda:/var/tmp/build-root/openSUSE_Factory_PowerPC-ppc/usr/lib/gcc/powerpc64-suse-linux/8# file crtbegin.o
crtbegin.o: ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (SYSV), not stripped

I would however argue that we should keep powerpc-suse-linux; in theory there's nothing stopping a SUSE derivative (or SUSE themselves if they want to do a mass-rebuild) from moving everything to powerpc-suse-linux and improving everyone's sanity.

This should also have a comment explaining why there's a 64-bit triple here for future readers.

This revision now requires changes to proceed.Dec 5 2018, 7:41 AM

Well, I agree on the comment to clarify why it has to be powerpc64-suse-linux, but I'm not sure whether anyone will ever start a SUSE derivative for 32-bit PowerPC, then fix the path in SUSE's gcc and then do a mass-rebuild. I think the probability is pretty low.

glaubitz updated this revision to Diff 176830.Dec 5 2018, 7:54 AM

Added a comment explaining the unusual triplet name.

nemanjai requested changes to this revision.Dec 29 2018, 2:19 PM

A couple of questions since I am not all that familiar with clang and am certainly not familiar with this unusual SUSE 32-bit situation:

  • We seem to be changing the set of aliases here, but what happens if someone actually explicitly specifies --target=powerpc-suse-linux?
  • Do we need to change anything about include paths?
  • Can you describe the default triple for clang on SUSE 32-bit PPC? Will it be powerpc-suse-linux? powerpc64-suse-linux?
  • Will this change not affect 64-bit PPC SUSE? Namely will the default libraries on actual 64-bit PPC SUSE big endian systems now be 32-bit libraries?
  • Can you please add a test case and a patch with full context before this patch can go any further?
This revision now requires changes to proceed.Dec 29 2018, 2:19 PM

A couple of questions since I am not all that familiar with clang and am certainly not familiar with this unusual SUSE 32-bit situation:

  • We seem to be changing the set of aliases here, but what happens if someone actually explicitly specifies --target=powerpc-suse-linux?

This is just the name of GCCDIST that is adjusted.

  • Do we need to change anything about include paths?

No.

On an openSUSE machine on ppc, we have:

:/usr # ls -l /usr/lib/gcc/
total 0
drwxr-xr-x 3 root root 15 Nov 19 23:27 powerpc64-suse-linux
:/usr # ls -dl /usr/power*
drwxr-xr-x 5 root root 43 May 25  2018 /usr/powerpc-suse-linux
:/usr #
  • Can you describe the default triple for clang on SUSE 32-bit PPC? Will it be powerpc-suse-linux? powerpc64-suse-linux?

I have to verify this.

  • Will this change not affect 64-bit PPC SUSE? Namely will the default libraries on actual 64-bit PPC SUSE big endian systems now be 32-bit libraries?

No. There are separate compiler packages for ppc64 and ppc.

  • Can you please add a test case and a patch with full context before this patch can go any further?

Not sure what the proper test would be.

On a sidenote, the spec file for gcc8 in openSUSE has:

%define HOST_ARCH %(echo %{_host_cpu} | sed -e "s/i.86/i586/;s/ppc/powerpc/;s/sparc64.*/sparc64/;s/sparcv.*/sparc/;")
%ifarch ppc
%define GCCDIST powerpc64-suse-linux
%else
%ifarch %sparc
%define GCCDIST sparc64-suse-linux
%else
%ifarch %arm
%define GCCDIST %{HOST_ARCH}-suse-linux-gnueabi
%else
%define GCCDIST %{HOST_ARCH}-suse-linux
%endif
%endif
%endif

See: https://build.opensuse.org/package/view_file/devel:gcc/gcc8/gcc8.spec?expand=1

So, it's explicitly overriding GCCDIST on ppc to be powerpc64-suse-linux.

Do you plan to follow-up on these questions and comments?
At least the full context is needed and for the test case, I imagine it can be similar to other driver test cases. I imagine tools/clang/test/Driver/linux-ld.c can be augmented with this?

Herald added a project: Restricted Project. · View Herald TranscriptMar 31 2019, 5:54 AM
Herald added a subscriber: jdoerfert. · View Herald Transcript

Well, I don't really know what to add here. The GCCDIST path on 32-bit PowerPC SUSE distributions has always been "powerpc64-suse-linux" according to SUSE's gcc maintainer Richard Biener and my patch just fixes that.

We're already using this patch in openSUSE without any issues: https://build.opensuse.org/package/view_file/devel:tools:compiler/llvm7/clang-fix-powerpc-triplet.patch?expand=1

Sorry for warming this up again, but it would be nice to get rid of this patch in openSUSE.

  • Will this change not affect 64-bit PPC SUSE? Namely will the default libraries on actual 64-bit PPC SUSE big endian systems now be 32-bit libraries?

So I've had a look at the gcc packages on PowerPC and where they put their stuff.

on ppcon ppc64
32-bit gccgcc9 uses /usr/lib/gcc/powerpc64-suse-linux/9/gcc9-32bit uses /usr/lib64/gcc/powerpc64-suse-linux/9/32/
64-bit gccgcc9-64bit uses /usr/lib/gcc/powerpc64-suse-linux/9/64/gcc9 uses /usr/lib64/gcc/powerpc64-suse-linux/9/

For comparison, on x86:

on i586on x86_64
32-bit gccgcc9 uses /usr/lib/gcc/i586-suse-linux/9/gcc9-32bit uses /usr/lib64/gcc/x86_64-suse-linux/9/32/
64-bit gccnot availablegcc9 uses /usr/lib64/gcc/x86_64-suse-linux/9/

So on x86 we do indeed have different triples, but there is no conflict between 32-bit and 64-bit default libraries either way, because the alternative arch always sits in a subdirectory.

I'm not sure whether anyone will ever start a SUSE derivative for 32-bit PowerPC.

There is no such image currently, and the repositories are empty, so given the waning popularity of 32-bit PowerPC that's a valid assumption, I guess. I think that 32-bit binaries are only built to be available on 64-bit systems.

On an openSUSE machine on ppc, we have:

:/usr # ls -l /usr/lib/gcc/
total 0
drwxr-xr-x 3 root root 15 Nov 19 23:27 powerpc64-suse-linux
:/usr # ls -dl /usr/power*
drwxr-xr-x 5 root root 43 May 25  2018 /usr/powerpc-suse-linux
:/usr #

This one is a bit weird, why /usr/powerpc-suse-linux suddenly? And is that going to be a problem?

I see that packages that use Clang compile fine on ppc, e.g. include-what-you-use, but I'm still wondering why this works.

  • Can you please add a test case and a patch with full context before this patch can go any further?

Not sure what the proper test would be.

I guess something like the test for D32347: add a mock directory tree, and test that everything is set up correctly.

aaronpuchert commandeered this revision.Aug 28 2019, 6:48 PM
aaronpuchert added a reviewer: glaubitz.

Added a test case, verified that it fails before the change.

Pass correct Clang triple as argument to --target.

A couple of questions since I am not all that familiar with clang and am certainly not familiar with this unusual SUSE 32-bit situation:

  • We seem to be changing the set of aliases here, but what happens if someone actually explicitly specifies --target=powerpc-suse-linux?
  • Can you describe the default triple for clang on SUSE 32-bit PPC? Will it be powerpc-suse-linux? powerpc64-suse-linux?

This change does not affect the Clang triple, that is and will be powerpc-unknown-linux-gnu. It's just about where Clang looks for the GCC toolchain.

  • Do we need to change anything about include paths?

Most of them should be independent of the GCC triple, except for /usr/include/c++/<gcc-ver>/<gcc-triple>. That should also work with this change.

  • Will this change not affect 64-bit PPC SUSE? Namely will the default libraries on actual 64-bit PPC SUSE big endian systems now be 32-bit libraries?

No, the 32-bit libraries on a 64-bit system sit in a /32 subfolder.

@jrtc27, @nemanjai: Could you have a look again? I think I answered all your questions and wrote a test.

nemanjai accepted this revision.Tue, Nov 19, 4:44 AM

LGTM. Thanks for adding the test case.

This revision was not accepted when it landed; it landed in state Needs Review.Sat, Nov 23, 7:11 AM
This revision was automatically updated to reflect the committed changes.