1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
|
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pkgmetadata SYSTEM "https://www.gentoo.org/dtd/metadata.dtd">
<pkgmetadata>
<maintainer type="project">
<email>toolchain@gentoo.org</email>
<name>Gentoo Toolchain Project</name>
</maintainer>
<use>
<flag name="ada">Build the ADA language (GNAT) frontend</flag>
<flag name="cet" restrict=">=sys-devel/gcc-10">
Enable support for control flow hijacking protection.
On amd64, this provides Intel Control Flow Enforcement Technology (CET).
On arm64, this provides Branch Target Identification (BTI)
and Pointer Authentication Code (PAC) support.
This is only effective on amd64 or arm64.
Only provides benefits on newer CPUs. For Intel, the CPU
must be at least as new as Tiger Lake. For AMD, it must be
at least as new as Zen 3. This is harmless on older CPUs,
but provides no benefit either.
For ARM64, PAC was introduced in armv8.3-a, and BTI was
introduced in armv8.5-a.
When combined with USE=hardened on amd64, GCC will set -fcf-protection
by default when building software. The effect is minimal
on systems which do not support it, other than a possible
small increase in codesize for the NOPs. The generated
code is therefore compatible with i686 at the earliest.
On arm64, GCC will set -mbranch-protection=standard by default
when building software.
</flag>
<flag name="d">Enable support for the D programming language</flag>
<flag name="debug">
Enables GCC's 'checking' facility via --enable-checking=yes,extra,rtl.
This adds checks to various compiler passes for integrity and input
validation. This can help catch possible miscompilations early as
well as latent bugs which could become real problems in future, but
at the cost of slower compile times when using GCC.
Unrelated to backtraces.
</flag>
<flag name="default-stack-clash-protection">
Build packages with stack clash protection on by default as
a hardening measure.
This enables -fstack-clash-protection by default which protects against
large memory allocations allowing stack smashing.
May cause slightly increased codesize, but modern compilers
have been adapted to optimize well for this case, as
this mitigation is now quite common.
See https://developers.redhat.com/blog/2020/05/22/stack-clash-mitigation-in-gcc-part-3
and https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt.
</flag>
<flag name="default-znow">
Request full relocation on start from ld.so by default.
This sets the -z,now (BIND_NOW) flag by default on all linker invocations. By
resolving all dynamic symbols at application startup, parts of the program
can be made read-only as a hardening measure.
This is closely related to RELRO which is also separately
enabled by default.
In some applications with many unresolved symbols (heavily plugin based,
for example), startup time may be impacted.
</flag>
<flag name="fixed-point">Enable fixed-point arithmetic support for MIPS targets in gcc (Warning: significantly increases compile time!)</flag>
<flag name="go">Build the GCC Go language frontend.</flag>
<flag name="graphite">Add support for the framework for loop optimizations based on a polyhedral intermediate representation</flag>
<flag name="ieee-long-double">Use accelerated 128-bit IEEE long double ABI (ppc64le only)</flag>
<flag name="jit">Enable libgccjit so other applications can embed gcc for Just-In-Time compilation.</flag>
<flag name="libdiagnostics">Provide libdiagnostics (https://gcc.gnu.org/wiki/libdiagnostics). This also installs the 'sarif-replay' tool.</flag>
<flag name="libssp">Build SSP support into a dedicated library rather than use the code in the C library (DO NOT ENABLE THIS IF YOU DON'T KNOW WHAT IT DOES)</flag>
<flag name="lto">
Build using Link Time Optimizations (LTO).
Note that GCC is always built with support for building
other programs with LTO. This USE flag is for whether
GCC itself is built and optimized with LTO.
</flag>
<flag name="modula2">Build the GCC Modula-2 language frontend.</flag>
<flag name="objc">Build support for the Objective C code language</flag>
<flag name="objc++">Build support for the Objective C++ language</flag>
<flag name="objc-gc">Build support for the Objective C code language Garbage Collector</flag>
<flag name="pgo">
Build GCC using Profile Guided Optimization (PGO).
GCC will build itself and then analyze the just-built
binary and then rebuild itself using the data obtained
from analysis of codepaths taken.
It does not affect whether GCC itself supports PGO
when building other software.
This substantially increases the build time needed for
building GCC itself.
</flag>
<flag name="rust">Build support for the Rust language, installs gccrs.</flag>
<flag name="sanitize">
Build support for various sanitizer functions (ASAN/TSAN/etc...)
to find runtime problems in applications.
</flag>
<flag name="ssp">Build packages with stack smashing protection on by default</flag>
<flag name="systemtap">enable systemtap static probe points</flag>
<flag name="vtv">
Build support for virtual table verification (a C++ hardening feature).
This does not control whether GCC defaults to using VTV>
Note that actually using VTV breaks ABI and hence the whole
system must be built with -fvtable-verify.
</flag>
</use>
<upstream>
<remote-id type="cpe">cpe:/a:gnu:gcc</remote-id>
</upstream>
</pkgmetadata>
|
GitWeb