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

classic Classic list List threaded Threaded
14 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]"
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.
>
> 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)

I paid most attention to the later dates in the original email (end of
year and end of next March) and was caught a bit off guard by this
when it was recently mentioned on IRC. Thus I wanted to refresh this
topic on the list, and remind everyone that this is imminent - soon a
default `make universe` without external toolchain will not include
GCC 4.2.1 archs (mips, powerpc, sparc64).

Warner's patch is in progress in review D21942.
_______________________________________________
[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, Oct 8, 2019 at 11:40 AM Ed Maste <[hidden email]> wrote:

> 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.
> >
> > 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)
>
> I paid most attention to the later dates in the original email (end of
> year and end of next March) and was caught a bit off guard by this
> when it was recently mentioned on IRC. Thus I wanted to refresh this
> topic on the list, and remind everyone that this is imminent - soon a
> default `make universe` without external toolchain will not include
> GCC 4.2.1 archs (mips, powerpc, sparc64).
>
> Warner's patch is in progress in review D21942.
>

I've updated the patch to have a check for external toolchain for mips,
powerpc and sparc64, and skip the build if they aren't installed. The old
behavior is enabled by setting MAKE_OBSOLETE_GCC so if you want, you can
build the universe with the old soon-to-be-deleted in-tree 4.2 gcc, as
outlined in this thread.

I'd held off a little thinking that llvm 9.0 will have landed by now, but
it hasn't due to exp-run issues. Rather than stall until it's in the tree,
I'm planning on committing the review by the end of the week, assuming
testing is all green. When it lands in the tree, we can rejigger with the
new mips and/or powerpc support.

https://reviews.freebsd.org/D21942 is a handy link to the review.

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

Mark Linimon-2
On Tue, Oct 08, 2019 at 12:01:52PM -0600, Warner Losh wrote:
> I'd held off a little thinking that llvm 9.0 will have landed by now, but
> it hasn't due to exp-run issues. Rather than stall until it's in the tree,
> I'm planning on committing the review by the end of the week, assuming
> testing is all green.

The following is not an argument for or against the timeline, just some
more info.

tl:dr; yes it's a long message, the gist of which is "we're not quiiiite
ready on powerpc64."  If people don't have some time to sit down and go
through all of the gory details, I won't blame them ...

The exp-run test Warner cites above covers and only covers "test all port
builds against llvm9.0 in base, on amd64".

What it does *not* cover is "test all port builds against llvm.<any> in
base, on powerpc64".

I have been leading the charge on the latter, on the machine IBM has
loaned to us via OSU, "ppcdevref".  This is the testbed for "powerpc64
with clang as the base compiler."  Right now its base compiler is 8.0.1.
(This is due to a: we have not gotten around to 9.x yet, b: we are
still only ~95% of the way to identifying *just* the regressions in
that configuration.)

As of today, the early-adopter developers running powerpc64/llvm9x are
battling errors that are (for purposes of brevity) the union of the
ppcdevref errors and the above exp-run.  (Actually, there are some
disjoint entries -- let me elide that for now.)

So the list of regressions as of *today* on ppcdevref has just been
re-uploaded to:

  https://people.freebsd.org/~linimon/poudriere/blacklist.powerpc64.ppcdevref

Let me note, I am updating this file *rapidly*, sometimes more than
once per day.  It is full of sharp edges and snarky comments :-)

Anyone who wants to poke at the above data, please contact me off-list
or join us on #powerpc64 on EFNet, rather than replying here.

But, of particular concern are:

  databases/mariadb55-client
  databases/mysql55-client
  databases/percona55-client
  devel/kyra
  graphics/drm-legacy-kmod
  lang/rust
  net/samba410
  www/node* (I have patches for these)
  x11-toolkits/qt5-declarative

And, I'm sorry, I used to have a set of poudriere results uploaded
to www.lonesome.com that corresponed to the above, so that you could
view the #blocked.  But that VM instance has died and I don't have
the cycles to fix it right now.  But in brief, the kyra, rust, and
samba failures are problematic.

So, that's the list of things that will break immediately as soon as
the pylon.nyi.FreeBSD.org package builder is switched over to gcc-less.
Also, anyone who is on powerpc64-CURRENT-less-than-that-commit will
have to immediately update, if they want to use the new packages.
There is no way to mix-and-match.

The problem I am facing is that "people keep moving my cheese".  There
have been infrastructure changees, a default ports compiler change,
changes that affect big projects like kde, and even a few sweeping
changes that I have not yet fully accounted for -- and that's all
within the last month.

This week I am not as much "fighting my way up the hill" as I am
"crawling up the hill on hands and knees while pulling arrows out
of my back."  So, my pace of testing and fixing has slowed down.
Also, there are some patches (especially linker) that I have not
yet tested.

Finally, yes, I know, I've been told more than once that "tier-2
considerations cannot affect what is committed to -CURRENT".  So,
I get that.  But, if we switched today, there would still be a
pain-point, and that's the point of all the above text.

fwiw.

mcl
_______________________________________________
[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

Mark Linimon-2
"way to bury the lede, Mark"

A more succinct summary of my message is at:

  https://wiki.freebsd.org/powerpc/ports/PortsOnClang

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