Sparc64 doesn't care about you, and you shouldn't care about Sparc64

Sean Bruno sbruno at
Sun Nov 8 17:16:57 UTC 2015

Hash: SHA512

On 11/08/15 07:55, Marius Strobl wrote:
> On Wed, Nov 04, 2015 at 04:19:38PM -0700, Warner Losh wrote:
>>> On Nov 4, 2015, at 12:12 PM, Sean Bruno <sbruno at>
>>> wrote:
>>> So here's the thing, Sparc64 is *just* barely alive in
>>> FreeBSD.
>> Has anybody actually booted it off a newish tree?
> Yes, just works fine there as of r290419.
> root at v215:~ # uname -a FreeBSD 11.0-CURRENT FreeBSD
> 11.0-CURRENT #1 r290419: Thu Nov  5 23:01:37 CET 2015
> marius at  sparc64
>>> There is exactly 1 Sparc64 machine as a ref box being hosted at
>>> Yahoo for the project.  No new hardware is on the horizon.
> Over time, linimon@ and me independently tried to get more sparc64 
> machines there but failed. As far as I was involved the goal was
> to get hardware being offered for donation in the US there but it 
> turned out that's it's just impossible to coordinate that from
> over here. However, I've been told that the primary reason for
> getting rid of the collocation at Yahoo is to improve the situation
> with on-site maintenance. So getting sparc64 hosts set up it the
> project cluster may actually be feasible now. I probably should
> check with glen at .

Right, so ... we *can* go upon Ebay or accept donations of FreeBSD
compatible hardware for Sparc64.  My impression, is that this hardware
is quite old, but there is a large amount of it available.  There is
no support for newer Sun/Oracle machines as far as I know, and I think
that is more interesting than supporting machines that haven't been
manufactured in a decade.  If I'm wrong here, I welcome corrections.

> Anyway, how many arm, mips, powerpc and powerpc64 reference
> machines are there in the project cluster and available for general
> use by developers? If there were, what would you do with them?
> According to my experience, the very few !x86 machines that
> actually are in there aren't really useful without root access.

PPC:  2x power8 (donated/supported by Adrian), 1x Apple Xserve. (at ISC)
MIPS:  something at Sentex, but I have no knowledge.
ARMv6:  none, AFAIK
ARMv8 (aarch64):  Thunder-X at Sentex

Support for mips, mips64, armv6 and armv8 are being provided via
emulation.  Packages are being build in a similar method.  Developers
on these architectures don't actually need real hardware, they can
either use full system emulation or construct an emulated assisted
jail via qemu-user mode.

For personal use, there are many, *many* Atheros MIPS routers that can
be used for development.  The EdgeRouter Lite is a very good MIPS64
target.  The RPi and BeagleBone Black are excellent ARMv6 targets that
are fully supported with packages and releases.  Sparc64 machines can
be trivially acquired via Ebay.

>>> None of the newer Sparc64 processors have been tested to work
>>> on FreeBSD and nobody is clamoring to get them working.
> Unlike x86, sun4u and sun4v CPUs are only designed to be backwards 
> compatible as far as the userland is concerned,
> host-PCI{,e}-bridges aren't compatible etc. So the kernel side
> always needs work and it simply isn't a matter of "testing" newer
> CPUs and models to work. Thus, the hardware is needed for
> developing support, see also below.
> I'm not sure at which point I'd speak of people "clamoring" for 
> support of some hardware; f. e. there also isn't a request for the
> graphics of Haswell and later Intel CPUs to be supported on the
> mailing lists every other day but you'll certainly agree that many
> are waiting for it. Now there likely are fewer people looking 
> forward for later sun4u and sun4v processors getting supported but 
> there definitely are people asking for it, just have a look at the 
> lists.
Now is the time for those users/people to step up and "clamor" for it.
 The example of Haswell graphics is a good point.  There is an active
developer working on the support with instructions on how to use the
test branch in github.  We don't have an equivalent project ongoing
for the Sparc64 target AFAIK.  I welcome being proven wrong here.

>>> We're moving into a post-gcc base system now, and sparc64 is
>>> the obvious "odd arch" here.  There's activity to get MIPS
>>> moved to clang and active work to get powerpc moved fully to
>>> clang.  Leaving Sparc64 in base, requires someone to either
>>> make clang DTRT or keep gcc 4.2.1-ish alive.
> I don't see why sparc64 would be "the obvious odd arch" in that 
> regard. The real problem is switching an architecture for which 
> clang might have gotten en par with GCC after clang was changed to
> require C++11 for bootstrap. Given that clang was only the default
> on arm and x86 at that point in time, we are now stuck without an
> in-tree upgrade path on all other architectures. Granted, that
> might be lesser a problem on mips as these machines typically don't
> have enough CPU and RAM that self-hosting would be interesting in
> the first place. That still puts sparc64 into the same boat as
> powerpc and powerpc64, though.

It's "obvious" to me from reading mailing lists and IRC chatter.  This
is a poor justification on my part as it requires participating in
these to see the "obviousness" of the argument.

I am personally pursuing clang enabled MIPS builds.  Others are moving
the MIPS target to enable support for gcc from ports.  Powerpc
developers have been working on clang and the clang intree is built
and installed in the powerpc images.  From my impression, there hasn't
been a similar push intree to do the same type of things for the
Sparc64 target.  Am I wrong here?

>> There was some work to get clang to do the right thing for
>> sparc64. Last I heard, the tree compiles with it. It didn?t boot,
>> but at the time gcc-compiled kernels didn?t boot either. I?m not
>> sure how this status has moved through time. It would be best to
>> ask Marius Strobl, since he?s the only one committing to sparc64
>> sub-tree lately non-global-sweep cleanups.
> Err, I'm sorry to say but pretty much all of these statements are 
> wrong or at least don't reflect reality properly. As for clang,
> initial support for 64-bit SPARC v9 and FreeBSD/sparc64 was added
> in the late 3.5.x times (I don't remember the exact version 
> offhand). Yes, it does compile FreeBSD userland but the majority
> of binaries do not work or put differently: For some strange reason
> a clang compiled sort(1) doesn't crash _and_ apparently does the
> right thing but I wasn't able to find any other program that worked
> correctly when compiled with clang. By installing clang-compiled
> system libraries one even totally hoses ones system, i. e. then
> also sort(1) instantly crashes. With clang 3.6.0 that got even
> worse; the front-end was changed to select soft-float by default
> but the back-end didn't have support for choosing between hard- and
> soft-float for 64-bit SPARC v9 so every compiler invocation just
> bailed out. As a side note: I couldn't spot any code that would
> suggest that hard-float support is implemented, which should be the
> actual default, though. I fixed that (the soft- float defaulting
> that is, not implementing hard-float support) and some other
> astonishing bugs (or rather: hacked some things into shape), which
> got some more things working and IIRC even a clang- compiled kernel
> got considerably further. However, I didn't get anywhere near the
> bottom of bugs and missing features. Generally, clang on sparc64
> gives more of an impression that it never has faced a compiler
> test-suite. I haven't given clang 3.7.0 a try thus far but the
> release notes and source changes don't suggest much has improved in
> that regard since then. Also, for me a toolchain is just what the
> name implies: A tool. If it isn't sufficiently close to 100 %
> working I just use another one.
> Regarding GCC-compiled kernles not working on sparc64 at that
> point I'm not aware of such a problem in that time frame or
> generally of a sparc64-specific breakage in the last couple of
> years (there was one in userland a couple of months ago, though). I
> mean, sure, the kernel build gets broken regularly as people don't
> even compile-test their changes and sometimes that also results in
> run-time problems but that certainly isn't what you are referring
> to. However, I can't think of a sparc64 kernel breakage that got
> beyond that or even was sparc64-specific. What you _might_ be
> thinking of in that regard is the following: When 64-bit SPARC v9
> and FreeBSD/sparc64 support initially were added, clang couldn't
> cope with code in the sparc64 pcpu.h. There was a patch by jmg@
> floating around which changed pcpu.h so that clang could compile a
> kernel. However, that patch conceptually is wrong and results in a
> non-working kernel even with GCC. Meanwhile, clang has been taught
> to grok at least the code in pcpu.h (but not generally to deal with
> the pattern in question), so at least that situation has improved
> and said patch is obsolete.
> As for getting forward, the FreeBSD Software License Policy 
> ( 
> specifically allows for existing GPLv2 licensed software in the
> FreeBSD source tree to be updated to GPLv3 licensed one. The
> initial, longer draft of this policy posted by brooks@ to 
> developers@ even explicitly mentioned key technologies such as
> toolchains of other licenses being allowed when no mature 
> BSD-licensed alternative exists. So I propose just that: Let's
> upgrade binutils and GCC in base to recent versions. Seriously.
> That way we 1) don't need to get external toolchain support into
> shape, 2) don't need to solve the chicken-and-egg problem of
> getting a toolchain onto a machine installed from a distribution
> built with an external toolchain and 3) once clang becomes mature
> on additional architectures, we have an upgrade path. Don't get me
> wrong, I'm only proposing that for !arm and !x86.

I'm totally behind this.  binutils is so busted and old that this
would definitely make my MIPS work much easier.  I'm not a binutils
maintainer and I'm super confused, since this policy exists, as to why
it has not been done yet.

> As a side note: A while back I talked to grehan@ and marcel@ 
> regarding the immaturities of clang and - as expected -, a GPL'ed
> toolchain just is no problem for either NetApp or Juniper as the
> binaries they ship don't include the toolchain itself. With the
> possible exception of the current incarnation of SCO which
> apparently sells a FreeBSD-based OS likely having a system
> compiler, for the same reason I can't think of why a GPLv3 licensed
> toolchain would matter for any of the commercial downstream
> consumers of FreeBSD. Thus, I really can't understand all that
> aggression regarding making FreeBSD 11 clang-only.

I don't like a mono-culture of toolchains.  I don't want to leave
unsupported tools and compilers in our system and I see no reason why
we shouldn't being considering updating gcc/binutils if it is allowable.

Version: GnuPG v2


More information about the freebsd-sparc64 mailing list