Gcc 4.2.1 to be removed before FreeBSD 13, a firm timeline

[Pedro Giffuni]

On 13/08/2019 18:09, Warner Losh wrote:
>
>
> On Tue, Aug 13, 2019 at 2:49 PM Pedro Giffuni <pfg at freebsd.org 
> <mailto:pfg at 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.