Date: Tue, 13 Aug 2019 19:48:10 -0500 From: Pedro Giffuni <pfg@FreeBSD.org> To: Warner Losh <imp@bsdimp.com> 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: <da2d60f4-a2f6-b979-f41a-9fa0b0e4c677@FreeBSD.org> In-Reply-To: <CANCZdfqDQgYDjxm%2BzM1x7TQx2csAAxhLBaKSbgjbZOLaZF3V0Q@mail.gmail.com> References: <542de336-f030-04f9-27d4-bebc96ab20fd@FreeBSD.org> <CANCZdfqDQgYDjxm%2BzM1x7TQx2csAAxhLBaKSbgjbZOLaZF3V0Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 13/08/2019 18:09, Warner Losh wrote: > > > On Tue, Aug 13, 2019 at 2:49 PM Pedro Giffuni <pfg@freebsd.org > <mailto: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. The GSoC2015 has a rather clean implementation (of the library, the headers are quite another issue): https://wiki.freebsd.org/SummerOfCode2015/FreeBSDLibcSecurityExtensions If we want to get FORTIFY_SOURCE working with clang, then we should look at a newer bionic(Android) instead but most of that is C++. Last time I looked, musl had an only-header implementation that works on modern GCC only. In any case I if replacing the library is the solution, I would strip out all the functions/symbols that are not in the GNU libssp. > It's likely a few hours of somebody's time to create. s/hours/nights/ > 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? > Only antoine@ would know, but by the looks of it, the best is to try the patch in a VM. Hope that helps, Pedro.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?da2d60f4-a2f6-b979-f41a-9fa0b0e4c677>