Re: What's the plan for powerpc64 in FreeBSD 16

On Tue, 10 Feb 2026 00:45:05 +0000
Minsoo Choo <[email protected]> wrote:

> On Monday, November 17th, 2025 at 11:58 AM, Warner Losh
> <[email protected]> wrote:
> 
> > Greetings,
> >
> > As we're getting close to the release date for FreeBSD 15.0, it's
> > time to take stock of another architectures. This time, I'd like
> > your feedback on the following plans.
> >
> > We'd like to retire powerpc64 and powerpc64le just before the
> > FreeBSD stable/16 branch.
> >
> > This would give powerpc64 another two years of support in main,
> > followed by sustaining support on stable/14 and stable/15 until the
> > end of those branches.
> >
> > We've come to this point because the port is dwindling and we have
> > a cost associated with keeping it around. The number of developers
> > has fallen off so only a couple remain. Issues in powerpc are
> > taking longer and longer to discover and resolve. The hardware has
> > been a huge source of frustration for clusteradmin and we've no
> > alternative for developers. There's only a tiny user base. We have
> > trouble building packages for it. Also, powerpc has a number of
> > interesting features of the architecture that make it the odd arch
> > out.
> >
> > It's also big endian. While that may seem like a reason to keep it
> > around, if we really can't support it and we're not actively
> > testing functionality of the system, then keeping this around
> > actually doesn't help keep us honest. It just gives us a burden we
> > must bear.
> >
> > In my opinion, powerpc64 appears to have already fallen below
> > critical mass, despite being a sentimental favorite for a number of
> > FreeBSD developers. As such, I'd like us to consider planning to
> > retire it before we branch 16.
> >
> > My questions today: Are you using this port? How many people are
> > using it? And what's the installed base? It appears to be somewhat
> > less than that of either i386 or armv7 based on user surveys and
> > popularity at conferences. Also, any other comments you might have.
> >
> > Warner  
> 
> I've been working on LLDB for several weeks now. One thing I learned:
> we should never expect improvement in ppc64be support for LLVM (at
> least in LLDB). ppc64be POSIX userland debugging on LLDB is
> incomplete—it's missing files that even riscv and loongarch implement
> and VSX registers are completely absent in some cases while ppc64le
> debugging is still actively developed and maintained. Debugging is
> one of the most crucial component in software development while LLVM
> is FreeBSD's default toolchain. In this context, I don't see any
> reason to keep support ppc64be. I was going to implement LLDB
> userland and kernel debugging support for all supported architectures
> from FreeBSD 14, but after I examined the current status of ppc64be
> in LLDB, I decided to abandon it.
> 
> And this is industry trend. The only ppc manufacturer for POSIX
> platforms, IBM, has been moving away from ppc64be. Major Linux
> distros, including developed by IBM subsidiary RedHat, only offer
> ppc64le binaries (RedHat and clones, CentOS, Fedora, SUSE, etc). Many
> drivers assume that the host is running on little-endian, so those
> drivers fail to work on big-endian systems. ppc64be is poorly
> maintained and tested across many OSes and I don't see why we should
> continue supporting it when there is no benefit.
> 
> --
> Minsoo
> 
>   

Please document all the deficiencies you find.  I'm still a major
proponent of BE architecture, if only for nostalgia sake.  Also, as
Adrian pointed out, it makes us better overall if we keep BE around,
because it helps reduce complacency from developers, as we know that
not all is x86, not all is LE, not all is Linux.

As for LLDB, I did the original port to powerpc64 back in 2014, and
that targeted BE.  It had some rough edges, and it was all rewritten
later.  But it shouldn't be a significant effort to get BE working
again in LLDB, it just requires someone with time to do it, and since
you brought it up (I wasn't aware that it was broken on BE only until
now) I can take a look at it.  I typically go for GDB when I debug, as
it's a much more mature and familiar debugger.

So far the only reason I see for favoring LE in software is that
recent OpenGL and its spinoff(s) have forced graphics memory
representation to be visible as "native endian", and GPUs got rid of BE
mode long ago.  An interesting note here is that Book-E PowerPC has
page-level endian setting, so we could theoretically support DRI on the
newer cards that need LE on devices with those CPUs (AmigaOne X5000 and
the new one developed by the powerpc-notebook project) with little
effort.  But for anything that doesn't have this word-level "native
visible" requirement, and instead has a strict byte order requirement,
there is absolutely no reason to force LE, as we already have all of
the macros and infrastructure needed to do the translation as needed;
developers only need to use it, which is not at all difficult when it's
documented by the vendor in some fashion.

- Justin