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

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Warner Losh
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.

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’s long past time to have a firm plan for 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’s now completely sufficient to
move to the next phase of removing gcc 4.2.1 from the tree.

We already have gcc 6.4 as an xtoolchain on amd64 in CI. This should
somewhat mitigate the risk for cross-compiler portability. This is a
long-established part of our CI. We want to retain gcc support for modern
versions of gcc since its debuggability is higher. Notifications for this
are currently turned off, but will be enabled soon. It’s expected that this
always will be working later in the year. We’ll work to update the
committers guide to reflect this, as well as give a recipe for testing.

The first phase will be at the end of the month. We’ll turn off -Werror on
gcc 4.2.1 (and MFC it to stable/11 and stable/12). We’ll then stop building
all platforms that require it as part of CI. New warnings will come up, but
will no longer waste developer time in trying to fix. Gcc 4.2.1 platforms
will no longer be built as part of universe, unless you add
-DMAKE_OBSOLETE_GCC is added to the command line. We plan on implementing
this by 2019-08-31.

An experimental branch will be created that will remove gcc related bits to
expose gaps in planning and to come up with a list of action items needed
to ensure Tier 1 platforms are unaffected by the gcc removal. The timeline
for this is by the end of September.

Next, we’ll turn off building gcc by default. This will effectively break
all gcc platforms with in-tree compilers. The external toolchain support we
have will suffice here, and patches will be accepted for whatever
integration are needed for these platforms with our current ports /
packages. The onus for these changes will be squarely on people that want
the platforms to continue. However, as a stop-gap gcc building can be
turned on for those people transitioning gcc-only platforms until gcc 4.2.1
is removed. This will happen on or about 2019-12-31.

After a 3 month transition period, gcc 4.2.1 will be removed from the tree.
This will be done on or about 2020-03-31.

After an additional 2 month transition period, all those platforms that
have not integrated with the FreeBSD CI system, work in a make universe
with the proper packages installed, and are shown to boot on real hardware
will be removed from the tree. This will happen on or about 2020-05-31.

After an additional 2 month grace period, those platforms that require
external toolchain integration that aren’t supported by the release
engineer’s release scripts will be removed. This  will happen on or about
2020-07-31.

The timeline gives powerpc, mips, mips64, and sparc64 9 months to integrate
either into an in-tree compiler, or to have a proven external toolchain
solution. This is on top of the many-years-long warnings about this being
the end game of the clang integration.

This is the proposed timeline, but should there be a significant issue
that’s discovered, the timeline can be amended.

Also note: the all toolchains in tree discussions are specifically out of
bounds here. Let’s remove one compiler and get the infrastructure needed to
make external toolchains robust before embarking on that discussion.

Comments?

Warner
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Shawn Webb-3
On Tue, Aug 13, 2019 at 10:00:30AM -0600, Warner Losh wrote:
> Comments?

Kill it with fire.

--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

Tor-ified Signal:    +1 443-546-8752
Tor+XMPP+OTR:        [hidden email]
GPG Key ID:          0xFF2E67A277F8E1FA
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9  3633 C85B 0AF8 AB23 0FB2

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Justin Hibbits-3
In reply to this post by Warner Losh
On Tue, 13 Aug 2019 10:00:30 -0600
Warner Losh <[hidden email]> 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.
>
> 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’s long past time to have a firm plan for
> 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’s now
> completely sufficient to move to the next phase of removing gcc 4.2.1
> from the tree.
>
> We already have gcc 6.4 as an xtoolchain on amd64 in CI. This should
> somewhat mitigate the risk for cross-compiler portability. This is a
> long-established part of our CI. We want to retain gcc support for
> modern versions of gcc since its debuggability is higher.
> Notifications for this are currently turned off, but will be enabled
> soon. It’s expected that this always will be working later in the
> year. We’ll work to update the committers guide to reflect this, as
> well as give a recipe for testing.
>
> The first phase will be at the end of the month. We’ll turn off
> -Werror on gcc 4.2.1 (and MFC it to stable/11 and stable/12). We’ll
> then stop building all platforms that require it as part of CI. New
> warnings will come up, but will no longer waste developer time in
> trying to fix. Gcc 4.2.1 platforms will no longer be built as part of
> universe, unless you add -DMAKE_OBSOLETE_GCC is added to the command
> line. We plan on implementing this by 2019-08-31.
>
> An experimental branch will be created that will remove gcc related
> bits to expose gaps in planning and to come up with a list of action
> items needed to ensure Tier 1 platforms are unaffected by the gcc
> removal. The timeline for this is by the end of September.
>
> Next, we’ll turn off building gcc by default. This will effectively
> break all gcc platforms with in-tree compilers. The external
> toolchain support we have will suffice here, and patches will be
> accepted for whatever integration are needed for these platforms with
> our current ports / packages. The onus for these changes will be
> squarely on people that want the platforms to continue. However, as a
> stop-gap gcc building can be turned on for those people transitioning
> gcc-only platforms until gcc 4.2.1 is removed. This will happen on or
> about 2019-12-31.
>
> After a 3 month transition period, gcc 4.2.1 will be removed from the
> tree. This will be done on or about 2020-03-31.
>
> After an additional 2 month transition period, all those platforms
> that have not integrated with the FreeBSD CI system, work in a make
> universe with the proper packages installed, and are shown to boot on
> real hardware will be removed from the tree. This will happen on or
> about 2020-05-31.
>
> After an additional 2 month grace period, those platforms that require
> external toolchain integration that aren’t supported by the release
> engineer’s release scripts will be removed. This  will happen on or
> about 2020-07-31.
>
> The timeline gives powerpc, mips, mips64, and sparc64 9 months to
> integrate either into an in-tree compiler, or to have a proven
> external toolchain solution. This is on top of the many-years-long
> warnings about this being the end game of the clang integration.
>
> This is the proposed timeline, but should there be a significant issue
> that’s discovered, the timeline can be amended.
>
> Also note: the all toolchains in tree discussions are specifically
> out of bounds here. Let’s remove one compiler and get the
> infrastructure needed to make external toolchains robust before
> embarking on that discussion.
>
> Comments?
>
> Warner

Hi Warner,

I like this proposal.  All powerpc targets (powerpc, powerpc64,
powerpcspe) will switch to clang when we get 9.0 into the tree, which
won't be until September or October.

That said, I think we should not MFC disabling -Werror on gcc 4.2.1 to
12 and 11, since we cannot MFC the clang migration for powerpc64 to 12,
as it will break the ABI (lld only supports ELFv2, not ELFv1).

- Justin
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Warner Losh
On Tue, Aug 13, 2019 at 10:30 AM Justin Hibbits <[hidden email]>
wrote:

> On Tue, 13 Aug 2019 10:00:30 -0600
> Warner Losh <[hidden email]> 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.
> >
> > 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’s long past time to have a firm plan for
> > 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’s now
> > completely sufficient to move to the next phase of removing gcc 4.2.1
> > from the tree.
> >
> > We already have gcc 6.4 as an xtoolchain on amd64 in CI. This should
> > somewhat mitigate the risk for cross-compiler portability. This is a
> > long-established part of our CI. We want to retain gcc support for
> > modern versions of gcc since its debuggability is higher.
> > Notifications for this are currently turned off, but will be enabled
> > soon. It’s expected that this always will be working later in the
> > year. We’ll work to update the committers guide to reflect this, as
> > well as give a recipe for testing.
> >
> > The first phase will be at the end of the month. We’ll turn off
> > -Werror on gcc 4.2.1 (and MFC it to stable/11 and stable/12). We’ll
> > then stop building all platforms that require it as part of CI. New
> > warnings will come up, but will no longer waste developer time in
> > trying to fix. Gcc 4.2.1 platforms will no longer be built as part of
> > universe, unless you add -DMAKE_OBSOLETE_GCC is added to the command
> > line. We plan on implementing this by 2019-08-31.
> >
> > An experimental branch will be created that will remove gcc related
> > bits to expose gaps in planning and to come up with a list of action
> > items needed to ensure Tier 1 platforms are unaffected by the gcc
> > removal. The timeline for this is by the end of September.
> >
> > Next, we’ll turn off building gcc by default. This will effectively
> > break all gcc platforms with in-tree compilers. The external
> > toolchain support we have will suffice here, and patches will be
> > accepted for whatever integration are needed for these platforms with
> > our current ports / packages. The onus for these changes will be
> > squarely on people that want the platforms to continue. However, as a
> > stop-gap gcc building can be turned on for those people transitioning
> > gcc-only platforms until gcc 4.2.1 is removed. This will happen on or
> > about 2019-12-31.
> >
> > After a 3 month transition period, gcc 4.2.1 will be removed from the
> > tree. This will be done on or about 2020-03-31.
> >
> > After an additional 2 month transition period, all those platforms
> > that have not integrated with the FreeBSD CI system, work in a make
> > universe with the proper packages installed, and are shown to boot on
> > real hardware will be removed from the tree. This will happen on or
> > about 2020-05-31.
> >
> > After an additional 2 month grace period, those platforms that require
> > external toolchain integration that aren’t supported by the release
> > engineer’s release scripts will be removed. This  will happen on or
> > about 2020-07-31.
> >
> > The timeline gives powerpc, mips, mips64, and sparc64 9 months to
> > integrate either into an in-tree compiler, or to have a proven
> > external toolchain solution. This is on top of the many-years-long
> > warnings about this being the end game of the clang integration.
> >
> > This is the proposed timeline, but should there be a significant issue
> > that’s discovered, the timeline can be amended.
> >
> > Also note: the all toolchains in tree discussions are specifically
> > out of bounds here. Let’s remove one compiler and get the
> > infrastructure needed to make external toolchains robust before
> > embarking on that discussion.
> >
> > Comments?
> >
> > Warner
>
> Hi Warner,
>
> I like this proposal.  All powerpc targets (powerpc, powerpc64,
> powerpcspe) will switch to clang when we get 9.0 into the tree, which
> won't be until September or October.
>
> That said, I think we should not MFC disabling -Werror on gcc 4.2.1 to
> 12 and 11, since we cannot MFC the clang migration for powerpc64 to 12,
> as it will break the ABI (lld only supports ELFv2, not ELFv1).
>

Why would that be a problem? It will allow us to ease the MFCs that might
otherwise trigger errors because some new warning (likely bogus) is
triggered... It would make things easier to cope with not being able to MFC
the clang thing, I'd think. Am I missing something?

Warner
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Justin Hibbits-3
On Tue, 13 Aug 2019 10:39:45 -0600
Warner Losh <[hidden email]> wrote:

> On Tue, Aug 13, 2019 at 10:30 AM Justin Hibbits <[hidden email]>
> wrote:
>
> > On Tue, 13 Aug 2019 10:00:30 -0600
> > Warner Losh <[hidden email]> 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.
> > >
> > > 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’s long past time to have a firm plan
> > > for 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’s
> > > now completely sufficient to move to the next phase of removing
> > > gcc 4.2.1 from the tree.
> > >
> > > We already have gcc 6.4 as an xtoolchain on amd64 in CI. This
> > > should somewhat mitigate the risk for cross-compiler portability.
> > > This is a long-established part of our CI. We want to retain gcc
> > > support for modern versions of gcc since its debuggability is
> > > higher. Notifications for this are currently turned off, but will
> > > be enabled soon. It’s expected that this always will be working
> > > later in the year. We’ll work to update the committers guide to
> > > reflect this, as well as give a recipe for testing.
> > >
> > > The first phase will be at the end of the month. We’ll turn off
> > > -Werror on gcc 4.2.1 (and MFC it to stable/11 and stable/12).
> > > We’ll then stop building all platforms that require it as part of
> > > CI. New warnings will come up, but will no longer waste developer
> > > time in trying to fix. Gcc 4.2.1 platforms will no longer be
> > > built as part of universe, unless you add -DMAKE_OBSOLETE_GCC is
> > > added to the command line. We plan on implementing this by
> > > 2019-08-31.
> > >
> > > An experimental branch will be created that will remove gcc
> > > related bits to expose gaps in planning and to come up with a
> > > list of action items needed to ensure Tier 1 platforms are
> > > unaffected by the gcc removal. The timeline for this is by the
> > > end of September.
> > >
> > > Next, we’ll turn off building gcc by default. This will
> > > effectively break all gcc platforms with in-tree compilers. The
> > > external toolchain support we have will suffice here, and patches
> > > will be accepted for whatever integration are needed for these
> > > platforms with our current ports / packages. The onus for these
> > > changes will be squarely on people that want the platforms to
> > > continue. However, as a stop-gap gcc building can be turned on
> > > for those people transitioning gcc-only platforms until gcc 4.2.1
> > > is removed. This will happen on or about 2019-12-31.
> > >
> > > After a 3 month transition period, gcc 4.2.1 will be removed from
> > > the tree. This will be done on or about 2020-03-31.
> > >
> > > After an additional 2 month transition period, all those platforms
> > > that have not integrated with the FreeBSD CI system, work in a
> > > make universe with the proper packages installed, and are shown
> > > to boot on real hardware will be removed from the tree. This will
> > > happen on or about 2020-05-31.
> > >
> > > After an additional 2 month grace period, those platforms that
> > > require external toolchain integration that aren’t supported by
> > > the release engineer’s release scripts will be removed. This
> > > will happen on or about 2020-07-31.
> > >
> > > The timeline gives powerpc, mips, mips64, and sparc64 9 months to
> > > integrate either into an in-tree compiler, or to have a proven
> > > external toolchain solution. This is on top of the many-years-long
> > > warnings about this being the end game of the clang integration.
> > >
> > > This is the proposed timeline, but should there be a significant
> > > issue that’s discovered, the timeline can be amended.
> > >
> > > Also note: the all toolchains in tree discussions are specifically
> > > out of bounds here. Let’s remove one compiler and get the
> > > infrastructure needed to make external toolchains robust before
> > > embarking on that discussion.
> > >
> > > Comments?
> > >
> > > Warner  
> >
> > Hi Warner,
> >
> > I like this proposal.  All powerpc targets (powerpc, powerpc64,
> > powerpcspe) will switch to clang when we get 9.0 into the tree,
> > which won't be until September or October.
> >
> > That said, I think we should not MFC disabling -Werror on gcc 4.2.1
> > to 12 and 11, since we cannot MFC the clang migration for powerpc64
> > to 12, as it will break the ABI (lld only supports ELFv2, not
> > ELFv1).
>
> Why would that be a problem? It will allow us to ease the MFCs that
> might otherwise trigger errors because some new warning (likely
> bogus) is triggered... It would make things easier to cope with not
> being able to MFC the clang thing, I'd think. Am I missing something?
>
> Warner

Good point.  The concern I have is legitimate warnings getting lost.
However, that can probably be dealt with without too much hassle, on a
case-by-case basis.

- Justin
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Brooks Davis-2
In reply to this post by Warner Losh
On Tue, Aug 13, 2019 at 10:00:30AM -0600, Warner Losh 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.

Thank you for writing this up.

> The timeline gives powerpc, mips, mips64, and sparc64 9 months to integrate
> either into an in-tree compiler, or to have a proven external toolchain
> solution. This is on top of the many-years-long warnings about this being
> the end game of the clang integration.

We'll find time at $DAYJOB to get mips64 over the last hurdles if
someone doesn't beat us there since we still need it until we get our
CHERI RISC-V port up and stable (and any PhD students whose work depends
on MIPS graduate).

-- Brooks

signature.asc (465 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Pedro Giffuni-4
In reply to this post by Warner Losh
> 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

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.

Pedro.



_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Warner Losh
On Tue, Aug 13, 2019 at 2:49 PM Pedro Giffuni <[hidden email]> 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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Ed Maste-2
In reply to this post by Warner Losh
On Tue, 13 Aug 2019 at 12:00, Warner Losh <[hidden email]> 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.

PR 228919 [1] is open to track GCC 4.2.1 removal, and the dependency
tree view [2] provides a convenient way to see the open identified
issues that need to be addressed.

[1] https://bugs.freebsd.org/228919
[2] https://bugs.freebsd.org/bugzilla/showdependencytree.cgi?id=228919&hide_resolved=1
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Pedro Giffuni-4
In reply to this post by Warner Losh

On 13/08/2019 18:09, Warner Losh wrote:

>
>
> On Tue, Aug 13, 2019 at 2:49 PM Pedro Giffuni <[hidden email]
> <mailto:[hidden email]>> 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.

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"