freebsd stable - Oct 2015 - STABLE clang planned update MFC path (3.4.1 STABLE, 3.7.0, CURRENT) vs. powerpc64

On 2014-Oct-11 Dimitry Andric wrote:
> On 11 Oct 2015, at 14:05, Piotr Kubaj <pkubaj at riseup.net
> > wrote:
> >
> > 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.
> 
> 
> 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:
> 
> * 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.
> 
> 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.
> 
> 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).
> 
> -Dimitry
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:

CC:=            gcc
COMPILER_TYPE:= gcc

which is not in stable/10's variant.

stable/10 has a lib/csu/powerpc64/Makefile that does not force gcc but still
has:

CFLAGS+=        -I${.CURDIR}/../common \
                -I${.CURDIR}/../../libc/include \
                -mlongcall

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.

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.

(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.)

==Mark Millard
markmi at dsl-only.net

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.

==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:
> 
>> On 11 Oct 2015, at 14:05, Piotr Kubaj <pkubaj at riseup.net
>>> wrote:
>>> 
>>> 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.
>> 
>> 
>> 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:
>> 
>> * 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.
>> 
>> 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.
>> 
>> 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).
>> 
>> -Dimitry
> 
> 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:
> 
> CC:=            gcc
> COMPILER_TYPE:= gcc
> 
> which is not in stable/10's variant.
> 
> stable/10 has a lib/csu/powerpc64/Makefile that does not force gcc but
still has:
> 
> CFLAGS+=        -I${.CURDIR}/../common \
>                -I${.CURDIR}/../../libc/include \
>                -mlongcall
> 
> 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.
> 
> 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.
> 
> (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.)
> 
> ==> Mark Millard
> markmi at dsl-only.net