Date: Mon, 23 Oct 2017 22:39:52 +0200 From: Marius Strobl <marius@freebsd.org> To: "Ngie Cooper (yaneurabeya)" <yaneurabeya@gmail.com> Cc: Mark Linimon <linimon@lonesome.com>, "A. Wilcox" <AWilcox@Wilcox-Tech.com>, Gerald Pfeifer <gerald@pfeifer.com>, freebsd-sparc64@FreeBSD.org, freebsd-arch@freebsd.org Subject: Re: future of sparc64 (was: Making C++11 a hard requirement for FreeBSD) Message-ID: <20171023203952.GB51868@alchemy.franken.de> In-Reply-To: <CB71FA85-BBE1-4633-990C-4AB10A91D071@gmail.com> References: <CANCZdfq5=KRp4NYKsc15gyS9C7CxrBFxcKQLPwnb_0oPb15vJw@mail.gmail.com> <20171005234149.GE8557@spindle.one-eyed-alien.net> <59D6CA6C.1040502@Wilcox-Tech.com> <20171007174124.GA20810@lonesome.com> <20171010211428.GA51868@alchemy.franken.de> <CB71FA85-BBE1-4633-990C-4AB10A91D071@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Oct 22, 2017 at 10:47:03PM -0700, Ngie Cooper (yaneurabeya) wrote: > > > On Oct 10, 2017, at 14:14, Marius Strobl <marius@freebsd.org> wrote: > > > > On Sat, Oct 07, 2017 at 12:41:24PM -0500, Mark Linimon wrote: > >> > >> All gccs > 4.9 fail to build. Looking at the logs AFAICT the failure > >> is a floating-point exception as soon as the first built binary is run > >> during the internal testing. > > > > The most plausible cause for that is executables and/or dynamic libraries > > not installing the user trap handlers as specified by the libc 64 psABI, > > i. e. not call __sparc_utrap_setup(). Do the ports GCCs use their own CRT > > nowadays? Do they no longer link libc last? Please provide their linker > > invocation. Also, please provide the backtrace of a minimal program > > exhibiting that problem. > > An idea occurred to me (after having dealt with building things over, and over, and over, this weekend): since we can?t rely on the ABI on ^/head to be stable, why don?t we produce working dynamic/static toolchains on HEAD-1 in ports, then require them for the areas that can?t bootstrap (yet, or at all?) with clang? We?ve already done that with some of our code that?s been deorbited from base (like rsh, etc). I don?t see why making a toolchain based on a stable ABI for architectures that will migrate or will be killed off needs to be a huge undertaking (politically), and needs to hold us back from making progress using a compiler that implements an almost 7 year old C++ spec. To be honest, I've no idea what your proposal has to do with the above, what it actually is about or why rsh(1) would be a viable example in this case given that rsh(1) hardly is a bootstrapping tool. However, ABI changes (the above wasn't about a change in ABI, btw.) are just one good example why an external toolchain would be a PITA as system compiler. Think of when we e. g. turned on TLS in the base compiler configurations after having added TLS support to rtld(1). The next buildworld ensured that not only the compiler used TLS, but also that an rtld(1) capable of TLS will be in place. Now with a similar future change and an external toolchain built on HEAD - 1, some additional magic would be needed to ensure that binaries built for HEAD use the expected ABI and all HEAD components are in sync. Generally, I'm fine with moving to an external toolchain for the system compiler, but only if it will also be the default for x86 so the life of tier-2 architectures won't become even harder - both politically and technically - as it is now. Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171023203952.GB51868>