Future Build Flag Changes on AOSC OS

[jyhi]

This is a tracking issue for a list of operations related to compiler flags in the (near or distant) future.

• Lint on *FLAGS, and new flags addition
  • References:
    • GCC Documentation (of course)
    • https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc/
• Lint on GCC Specs

For flag addition, there are some new GCC flags that only apply to newer version of GCC, and hence need to wait for the upgrade of compiler.

If you have more idea, update the list.

[jyhi]

Interesting flags we may want to consider:

• CFLAGS
  • -fexceptions "is recommended for hardening of multi-threaded C and C++ code" (RH)
  • -fstack-clash-protection "prevents attacks based on an overlapping heap and stack" (RH) [GCC8]
  • -mcet -fcf-protection "enables support for the Control-Flow Enforcement Technology (CET) feature in future Intel CPUs" (RH) [AMD64]
    • We don't seem to have the -mcet flag...
  • -Wl,-z,noexecstack disables executable stacks (however, this is still needed for many applications, especially JITs)
• CPPFLAGS
  • -D_GLIBCXX_ASSERTIONS enables additional C++ standard library hardening (RH)
• LDFLAGS
  • -Wl,--gc-sections instructs the linker to remove unnecessary sections from the final binary
    • Used with CFLAGS -ffunction-sections -fdata-sections
    • I see these flags everywhere saying that binary size can be reduced, but my personal experiments do not reflect obvious changes, and I think this will cause problems on libraries

Some flags are for better debugging:

• -g (RH)
  • "... even for optimized production builds. Having only partly usable debugging information (due to optimization) certainly beats having none at all" @LionNatsu
  • I see nothing different on my small project... It is stripping that interferes debugging I think
• -grecord-gcc-switches "store compiler flags in debugging information" (RH) (Debugging symbol will be stripped anyway)
• -fplugin=annobin "enables the annobin compiler plugin, which captures additional metadata to allow a determination of which compiler flags were used during the build" (RH)
  • I have no idea what this is

[jyhi]

Also we now enable -fpermissive by default. I personally think this is not a very good idea... and I propose a removal of this flag (given that Red Hat has several style-related compiler flags enabled).

[jyhi]

Previously we have many packages failed to be built because of PIE. I looked a little bit into our GCC specs, and found out that our hardened-ld specs are unaware of the status of input files: if the given object files are not compiled with -fPIC then the linker just deny to link with -pie. Our current resolution is disabling PIC across the package, which disables ASLR. NG.

And it turns out that GCC specs can be merged into one single file. My trial on this is successful.

[jyhi]

In c901619 we use -flto=jobserver instead of -flto=$ABTHREADS. Packagers may have seen this from time to time:

warning: jobserver unavailable: using -j1. Add `+' to parent make rule.

This means the (originally) parallel LTO process is downgraded to single-threaded, making the LTO process very slow. In addition, -flto=jobserver requires:

• GNU make
• Invoke children GNU make using $(MAKE) instead of just make in Makefile

If we do not alter packages, we may want to revert c901619 and force LTO to use as many cores as possible.

[jyhi]

For Rust packages, RUSTFLAGS environment variable can be set for cargo (The Rust package manager and build system) to apply to rustc, for not only the project itself but also all dependencies of it. For example:

export RUSTFLAGS="-C target-feature=+sse3 -C no-integrated-as"

LTO can be enabled too (theoretically), but there are limitations:

• "only 'staticlib', 'bin', and 'cdylib' outputs are supported with LTO" (rustc output). Thus, if we include -C lto in RUSTFLAGS, some crates (Rust projects, typically dependencies) will just fail to build.
  • One example is pest_derive, which is of type proc_macro
• To apply only LTO on the project itself, cargo rustc instead of cargo build is required to be used to pass extra flags to rustc. While it is possible to do this for pure Rust packages, it is not very convenient to inject such flag to Rust dependencies (e.g. Firefox (they may have LTO enabled by default!)).

Rust binaries are by default PIEs on many platforms, so we can leave it as-is.

[jyhi]

Experimentally we want to enable the following two options in GCC configuration:

• --enable-default-pie enables PIE by default (-fpie and -fPIE)
• --enable-default-ssp enables --fstack-protector-strong by default

This also avoids GCC specs problems (hopefully).

https://gcc.gnu.org/install/configure.html

[jyhi]

As @LionNatsu proposed, since some packages by default turn -march=native on, which breaks compatibility on machines less capable than the build machine, GCC specs may be used to strip such flags to avoid such problem. To achieve this without confusing users using GCC, a separate toolchain with such specs integrated and --enable-default-pie --enalbe-default-ssp may be packaged for distribution compilation use (because we want the -march=native stripping be the default).

Nonetheless, we haven't figured out how to do this yet.