Date: Sun, 11 Oct 2015 20:43:04 -0700 From: Mark Millard <markmi@dsl-only.net> To: freebsd-stable@freebsd.org Cc: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: STABLE clang planned update MFC path (3.4.1 STABLE, 3.7.0, CURRENT) vs. powerpc64 Message-ID: <EC125496-0781-4ABD-AC41-594D6C9E8A52@dsl-only.net> In-Reply-To: <7ABB859E-8321-48F7-885C-6667243C1388@dsl-only.net> References: <7ABB859E-8321-48F7-885C-6667243C1388@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
I had written (2015-Oct-11):
> I'm not sure about going all the way back to FreeBSD 9 but this =
suggests that clang was for some time --and recently has been-- =
insufficient on its own for reliable(?) powerpc64 builds (2015-Feb-05). =
It may be best to consider powerpc64 omitted from the "clang 3.4.1 and =
libc++" list in that last paragraph given the "upgrade easily" context =
intended.
But looking at stable/9 I see that -mlongcall is not in use in CFLAGS.
I would guess that stable/9 depended on code happening to be close =
enough together and it failed in other contexts. ("The" problems seem to =
move around.) I'll note that the 2012-Mar-13 stable/10 addition of =
-mlongcall was explained by (nwhitehorn's -r232932):
> Adding -mlongcall
> to crt1 flags causes the compiler to emit explicit TOC load =
instructions
> for all function calls, including _fini().
The reason for this being important was listed as:
> Work around a binutils bug on powerpc64 where the TOC would not be
> properly reloaded when calling _fini() in large binaries with multiple
> TOC sections (e.g. GCC), leading to a segmentation fault.
I'm still not sure that the stable/9 to stable/10 update would be =
reliably clean for powerpc64, despite -mlongcall not being used at that =
stage.
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
On 2015-Oct-11, at 8:05 PM, Mark Millard <markmi at dsl-only.net> wrote:
> On 2014-Oct-11 Dimitry Andric wrote:
>=20
>> On 11 Oct 2015, at 14:05, Piotr Kubaj <pkubaj at riseup.net
>>> wrote:
>>>=20
>>> AFAIK if there had been such plans, they were dropped long ago. The
>>> reasoning it can't be done (at least for now) is that versions =
3.5.0+
>>> require C++11-capable stack and that would break upgrades from =
9-STABLE
>>> (if the user still uses GCC, as is by default). So, LLVM in =
stable/10
>>> will probably be upgraded when stable/9 goes EOL.
>>=20
>>=20
>> If stable/10 had clang 3.5 or higher, you could still upgrade from
>> stable/9. It would only require you to do the upgrade in two steps:
>>=20
>> * Rebuild and reinstall your stable/9 world using WITH_CLANG,
>> WITH_CLANG_IS_CC, and WITH_LIBCPLUSPLUS. This will install clang
>> 3.4.1 and libc++, and make clang the default compiler.
>> * Checkout stable/10 (or even head), and build/install it in the =
regular
>> fashion.
>>=20
>> I am personally not against merging newer llvm/clang versions into
>> stable/10. But the "silent agreement" has always been that you could
>> upgrade easily from the latest stable/X to stable/X+1, and the above
>> two-step process breaks that, or at least makes it more complicated.
>>=20
>> Last but not least, note that this would only apply to the =
architectures
>> that *can* actually build clang 3.4.1 and libc++ on stable/9. This =
is
>> currently limited to x86, little-endian arm and powerpc (64 bit, I'm
>> unsure about 32 bit).
>>=20
>> -Dimitry
>=20
> lib/csu/powerpc64/Makefile in head has updates and comments =
(2015-Feb-05 or so) about "powerpc64 csu needs to be built by gcc, so =
enforce that". It is tied to clang not supporting -mlongcall and =
"testing shows a clang linked with a [#] clang-built csu segfaults". The =
forcing of gcc use in head looks like:
>=20
> CC:=3D gcc
> COMPILER_TYPE:=3D gcc
>=20
> which is not in stable/10's variant.
>=20
> stable/10 has a lib/csu/powerpc64/Makefile that does not force gcc but =
still has:
>=20
> CFLAGS+=3D -I${.CURDIR}/../common \
> -I${.CURDIR}/../../libc/include \
> -mlongcall
>=20
> and so has -mlongcall in use on the command lines. Unless -mlongcall =
support used to be in place for clang and was later removed, a =
rebuilding of FreeBSD 9 or 10 that includes a lib/csu/powerpc64/ rebuild =
likely fails to build under WITH_CLANG_IS_CC.
>=20
> I'm not sure about going all the way back to FreeBSD 9 but this =
suggests that clang was for some time --and recently has been-- =
insufficient on its own for reliable(?) powerpc64 builds (2015-Feb-05). =
It may be best to consider powerpc64 omitted from the "clang 3.4.1 and =
libc++" list in that last paragraph given the "upgrade easily" context =
intended.
>=20
> (If there is an easy powerpc64 upgrade then I'd like to see notes =
about it: Other contexts might be able to use similar techniques. I =
started my explorations with 10.)
>=20
> =3D=3D=3D
> Mark Millard
> markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EC125496-0781-4ABD-AC41-594D6C9E8A52>