Date: Mon, 21 Jan 2019 12:54:16 -0800 From: Mark Millard <marklmi@yahoo.com> To: Michael Tuexen <tuexen@freebsd.org> Cc: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: clang support Message-ID: <5CDCA7AB-395D-4AF0-9C2B-836F90DCDD17@yahoo.com> In-Reply-To: <CB4A1F8F-2816-477F-9400-D4BF28DBC9D0@freebsd.org> References: <CB4A1F8F-2816-477F-9400-D4BF28DBC9D0@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2019-Jan-21, at 11:55, Michael Tuexen <tuexen at freebsd.org> wrote: > Dear all, >=20 > what is the reason FreeBSD is not using clang on PPC, but still used = gcc. > Are there any plans to change it? lld? clang/clang++ mixed with the binutils ld? libunwind vs. libgcc_s unwindd facilities? The official FreeBSD clang7 or clang6 vintage vs. later in-developement materials? I sometimes experiment with what FreeBSD has in-tree for buildworld buildkernel and testing. Also with devel/powerpc64-xtoolchain-gcc related tooling. The overall answer for clang is that various things still do not work. I'll mostly ignore here freebsd bugs in libgcc_s handling of DW_CFA_remember_state and DW_CFA_restore_state that also apply to builds via gcc's after gcc 4.2.1 . (I run with a near- minimalist-text-change patch for this. =46rom other points of view it is suboptimal but I do nor care.) gcc 4.2.1 seems to mostly avoid those two for powerpc64 and powerpc and so seems to operate. I'll caution that the following are all "last I knew" as I've not repeated my experiments in a few months. Someone may know more recent status and there are folks working on versions after here FreeBSD is currently based. (I've not experimented with their materials.) clang does not correctly compile the libgcc_s unwind code, making thrown exceptions not work at all: the generated code crashes. __builtin_eh_return is parsed silently but ignored and so there is missing material in clang's output. (There could be more to it.) libunwind in FreeeBSD did not support targeting powerpc64 or powerpc for FreeBSD, even getting syntax errors in the assembler notation. So switching over is not yet an option. The kernel linkage handling and some of the clang-based kernel build's linkage generation were not matched, leading to dynamically loading kernel modules built by clang crashing. (I will not claim to know which side should change: I've never found a good reference for such areas for ABI requirements both are to meet.) I dealt with this by building-in what I wanted access to in order to do other experiments. lld just does not work yet for powerpc64 or powerpc. (I do not remember much detail here.) I do not try this as often, instead focusing on compiler output being correct for now.) It is possibly that I'll remember more later. I've had more success with devel/powerpc64-xtoolchain-gcc related tooling, although there is: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D232387 "head -r339076: system crash in vnet_epair_init during kern_jail_set in = a kyua test on powerpc64" so I've only been able to complete a: # kyua test -k /usr/tests/Kyuafile with a gcc 4.2.1 based kernel mixed with the more modern gcc based buildworld. (Something like my libgcc_s patch for DW_CFA_remember_state and DW_CFA_restore_state is required because kyua uses thrown C++ exceptions extensively to operate.) Bugzilla 232387 may be another linkage mismatch between what the kernel handles and what the compiler/linker generates, although I do not remember the details at the moment. I have also experimented with base/gcc and base/binutils but mostly devel/powerpc64-xtoolchain-gcc related tooling. So I do not otherwise comment on base/gcc and base/binutils here. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5CDCA7AB-395D-4AF0-9C2B-836F90DCDD17>