Date: Tue, 13 Aug 2019 17:09:50 -0600 From: Warner Losh <imp@bsdimp.com> To: Pedro Giffuni <pfg@freebsd.org> Cc: "freebsd-arch@freebsd.org" <arch@freebsd.org> Subject: Re: Gcc 4.2.1 to be removed before FreeBSD 13, a firm timeline Message-ID: <CANCZdfqDQgYDjxm%2BzM1x7TQx2csAAxhLBaKSbgjbZOLaZF3V0Q@mail.gmail.com> In-Reply-To: <542de336-f030-04f9-27d4-bebc96ab20fd@FreeBSD.org> References: <542de336-f030-04f9-27d4-bebc96ab20fd@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 13, 2019 at 2:49 PM Pedro Giffuni <pfg@freebsd.org> wrote: > Greetings, > > As promised for almost the past decade or so, gcc 4.2.1 will be removed > from the tree before FreeBSD 13 is branched. > > Yes !! > > I propose the following timeline for its removal: > > 2019-08-31: disconnect gcc 4.2.1 from CI build > > Turn off -Werror on gcc 4.2.1 platforms > > Turn off all gcc 4.2.1 from universe by default (can be turned on) > > 2019-12-31: Turn off gcc 4.2.1 build by default (can be turned on) > > 2020-03-31: svn rm gcc 4.2.1 and friends > > 2020-05-31: svn rm all non-clang platforms not supported by in-tree LLVM or > converted to ext toolchain. > > 2020-07-31: svn rm all ext toolchain platforms not supported by re@ release > scripts > > The basic notion is that it=E2=80=99s long past time to have a firm plan fo= > r EOL > gcc 4.2.1 in the tree. There is ample external toolchain support today for > platforms that need it to build images, though that integration with > buildworld could use some more polish. It=E2=80=99s now completely sufficie= > nt to > move to the next phase of removing gcc 4.2.1 from the tree. > > > snip ... all fine stuff ... > > Comments? > > I/we have a problem with libssp (part of gcclibs). > > Short story: I have tried to get rid of libssp twice, but I failed and > would appreciate someone with more compiler foo looking at it: > > https://reviews.freebsd.org/D15687 > > Also PR 229348 > Yes. This is a known issue that we have a squishy plan for. Obviously, if we can't execute on the squishy plan, we'd have to re-valuate the timeline. > Longer story: libssp was brought along with the stack-protector after > similar code from NetBSD, however the stack protector code lives in our > libc already (libc/secure/stack_protector.c). libssp is used to support > FORTIFY_SOURCE, a feature which we never ported to FreeBSD and remains > unused. > > FWIW, I mentored the implementation of FORTIFY_SOURCE in GSoC2015 but we > only got it working fully with GCC 4.2.1: it is largely unsupported by > clang and obsoleted by stack-protector-strong. NetBSD doesn't use the > libssp included with GCC, they have their own BSD licensed version, > however, given that we don't use it at all it doesn't make sense to import > it. We should just get rid of it but the libary seems to have grown roots > in the compiler toolchain and even when I am able to build world without > it, and exp-run thinks the compiler is broken. > Yes. There is also another MIT/BSD licensed implementation that was mentioned when we were putting together the proposed timeline, as was doing a clean-room implementation as needed. It's likely a few hours of somebody's time to create. I don't recall the details. Thanks for the pointers, and the confirmation that we almost certainly need to fill this gap. Any chance there's a pointer to the exp run that shows the failures? Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqDQgYDjxm%2BzM1x7TQx2csAAxhLBaKSbgjbZOLaZF3V0Q>