Sparc64 support

[Roman Divacky]

Fwiw, there's been some fixes to the sparc64 backend in clang37, so you might
want to spend some more idle sparc cycles to build and test that.

Anyway, marius@ did an analysis of the sparc64 support in llvm last december
and reported a number of issues. I don't think those issues have been fixed.

If you want to try/analyse/fix those bugs you're more than welcome.

Roman

On Wed, Aug 12, 2015 at 06:46:01PM -0500, Bill Sorenson wrote:
> I just spent a day building clang36 from ports on one of my idle sparc
> machines, and it builds a working ubench binary. I'm going to see if I can
> build some ports with it but thus far the latest clang seems at least
> superficially functional on sparc. I know when I tired many moons ago,
> clang built binaries would instantly dump.
> 
> -Bill Sorenson
> 
> On Fri, Aug 7, 2015 at 2:53 PM, John Baldwin <jhb at freebsd.org> wrote:
> 
> > On Wednesday, August 05, 2015 02:10:34 PM Bill Sorenson wrote:
> > > I'm one of probably a few users of FreeBSD and OpenBSD on multiple
> > > platforms left and I thought I'd share some of my experience with BSD on
> > > some of the lesser used platforms.
> >
> > Realistically, the major potential bump in the road for sparc64 is the
> > toolchain.  GCC 4.2.1 is getting really long in the tooth and as a
> > Project we want to drop it as our system compiler.  I can't tell you
> > when that will happen, but it will eventually.  That means that all of
> > our supported platforms will either have to work with clang, or they will
> > need to use an external GCC toolchain (of more recent vintage).  Ensuring
> > that one of these routes work for sparc64 will make it much easier for
> > sparc64 to stay in the tree without inhibiting other work.
> >
> > My understanding is that the most recent clang in HEAD can at least build
> > and install on sparc64, but that programs built with it might segfault,
> > etc.  If you are up for debugging those issues then that is one approach.
> > I do think that clang works on Linux/sparc64, so that these should be
> > FreeBSD bugs moreso than clang/llvm bugs (but I can't promise that).
> >
> > In theory we have bits in our build system to use an external toolchain
> > for building a system.  I haven't worked with them but I have seen others
> > talk about them (e.g. imp@ and bapt@).  Getting the recipe down for how
> > to do it and testing that the system works with recent versions of
> > GCC is what is missing there I think (so that there are instructions of
> > 'install port foo', 'stick this in /etc/make.conf', or 'put this on the
> > command line to buildworld', etc.).  Of course, testing that the resulting
> > binaries also work correctly would also be good. :)
> >
> > --
> > John Baldwin
> >
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"