[PATCH 1/2] specs: load specs.overlay with all commands enabled
After automatically discovered "specs" file is loaded, or in its
absence "built-in" specs are generated; attempt to discover
"specs.overlay" and load it.
Unlike "specs", "specs.overlay" allows using "%include",
"%include_noerr" and "%rename" commands, similar to user provided
`-specs` on the command line.
Then continue to parse and load any user provided `-specs` on the
command line.
gcc/ChangeLog:
* gcc.cc (driver::set_up_specs): Parse and load specs.overlay
by default, with all commands allowed.
Signed-off-by: Dimitri John Ledkov
---
gcc/gcc.cc | 5 +
1 file changed, 5 insertions(+)
diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index 16fed46fb35..b00d93b45c4 100644
--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
@@ -8601,6 +8601,11 @@ driver::set_up_specs () const
PREFIX_PRIORITY_LAST, 0, 1);
}
+ /* Process any built-in specs overlay, allow include_noerr */
+ specs_file = find_a_file (&startfile_prefixes, "specs.overlay", R_OK, true);
+ if (specs_file != 0 && access (specs_file, R_OK) == 0)
+read_specs (specs_file, false, false);
+
/* Process any user specified specs in the order given on the command
line. */
for (struct user_specs *uptr = user_specs_head; uptr; uptr = uptr->next)
--
2.43.0
[PATCH 0/2] Enable supplementing built-in specs without command-line arguments
is no need to create a brand-new
file api "specs.overlay". But behavior of /specs will be
widely different across GCC releases, which may cause confusion if
this changes makes "specs" files popular again.
Today in the [Spec files] documentation it is not mentioned that when
creating a custom Spec file, and testing it with `-specs` command,
will result in widely different behavior if moved to
/specs location. As right now it is not mentioned that
'%include" commands are blocked, and that the built-in specs are not
loaded, meaning '%rename' and '+' append functionality effectively
cannot be used.
But only want to update documentation for all supported gcc series,
once there is consensus on any of the above proposals.
[Spec files]: https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html
[Clang config files] passed on commandline, work identical to the
automatically discovered ones. On commandline they are passed with
`--config`.
The configuration files language is more simple one. It is a flat text
file of comments, or literal command-line options appended. There is
one `@file` directive to include another file.
Automatic configuration file discovery uses compiler name and target
arch to discover and load a matching configuration file. For example
`x86_64-pc-linux-gnu-clang-g++`, tries to load
`x86_64-pc-linux-gnu-clang++.cfg`, or
`x86_64-pc-linux-gnu-clang-g++.cfg`, or `clang++.cfg`
[Clang config files]:
https://clang.llvm.org/docs/UsersManual.html#configuration-files
In addition to toolchain internal locations (typically under
`/usr/lib`), system-wide locations are also typically searched by
Clang, i.e. `/etc/clang-18`. An equivalent `/etc/gcc` spec files
discovery location does not exist today, but also not sure if it is
needed. Distributions can use symlinks, and dynamically generated spec
files with relevant includes as needed using their usual means to
manage such things (update-alternatives, dpkg-reconfigure, etc).
Equivalent to `--config` in GCC Spec file terms would be a `.cfg` file
that automatically injects all strings into `*self_spec: +` lines, and
converts `@file` includes into `#include_noerr` commands.
Shockingly enough I did set /specs to
```
*self_spec:
+ %{!O:%{!O1:%{!O2:%{!O3:%{!O0:%{!Os:%{!0fast:%{!0g:%{!0z:-O2}
-fhardened %{!Wall:%{!Wno-all:-Wall}} %{!Wformat=0:-Wformat=2}
%{!Wconversion:%{!Wno-conversion:-Wconversion}}
%{!Wimplicit-fallthrough=0:-Wimplicit-fallthrough=3}
-Wl,--as-needed,-O1,--sort-common,-z,noexecstack,-z,relro,-z,now
-fno-delete-null-pointer-checks -fno-strict-overflow -fno-strict-aliasing
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
-mDO_NOT_COPY_AND_PASTE_INTO_SPECS
```
and that actually manages to compile a huge number of C/C++ software
with common build systems, despite removing linking command and thus
removing `-lgcc_s` from the link command and actually miss-building
lots of things. (Intentionally added invalid arg to prevent others
making the same mistake with a blind copy & paste).
Dimitri John Ledkov (2):
specs: load specs.overlay with all commands enabled
specs: always generate built-in specs, before reading "specs" file
gcc/gcc.cc | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
--
2.43.0
[PATCH 2/2] specs: always generate built-in specs, before reading "specs" file
Previously either "specs" file was read, or built-in specs were
generated.
With this change, always load generated "built-in" specs, prior to
discovering and loading optional "specs" file.
Also relax, and allow using "%include", "%include_noerr", and
"%rename" commands in the "specs" file.
Then continue to load user specified `-specs` files on the command
line.
This makes "specs" file from startfiles locations, behave closer to
user provided "-specs" files.
gcc/ChangeLog:
* gcc.cc (driver::set_up_specs): Always load "built-in"
generated specs files, prior to loading "specs" file. Allow
"%include", "%include_noerr" and "%rename" commands in
"specs" file.
Signed-off-by: Dimitri John Ledkov
---
gcc/gcc.cc | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index b00d93b45c4..8d208e7de00 100644
--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
@@ -8464,12 +8464,18 @@ driver::set_up_specs () const
accel_dir_suffix, dir_separator_str, NULL);
just_machine_suffix = concat (spec_machine, dir_separator_str, NULL);
+ /* Always init built-in specs, as all followups can then
+ append/remove/rename. This also makes the existing Spec documentation true
+ for both command-line -specs provided files, and those added to the
+ /specs location */
+ init_spec ();
+
specs_file = find_a_file (&startfile_prefixes, "specs", R_OK, true);
- /* Read the specs file unless it is a default one. */
- if (specs_file != 0 && strcmp (specs_file, "specs"))
-read_specs (specs_file, true, false);
- else
-init_spec ();
+
+ /* Read the specs file, these days empty, thus allow #include_noerr
+ commands */
+ if (specs_file != 0)
+read_specs (specs_file, false, false);
#ifdef ACCEL_COMPILER
spec_machine_suffix = machine_suffix;
@@ -8485,7 +8491,7 @@ driver::set_up_specs () const
strcat (specs_file, spec_machine_suffix);
strcat (specs_file, "specs");
if (access (specs_file, R_OK) == 0)
-read_specs (specs_file, true, false);
+read_specs (specs_file, false, false);
/* Process any configure-time defaults specified for the command line
options, via OPTION_DEFAULT_SPECS. */
--
2.43.0
Re: [PATCH] driver: -fhardened and -z lazy/-z norelro [PR117739]
Did bootstrap with gcc-14 (clean cherrypick, minor offsets).
Built and tested on arm64 & x86_64.
It resolved the reported problem.
Thank you for this patch.
On Tue, 26 Nov 2024, 22:37 Marek Polacek, wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>
> -- >8 --
> As the manual states, using "-fhardened -fstack-protector" will produce
> a warning because -fhardened wants to enable -fstack-protector-strong,
> but it can't since it's been overriden by the weaker -fstack-protector.
>
> -fhardened also attempts to enable -Wl,-z,relro,-z,now. By the same
> logic as above, "-fhardened -z norelro" or "-fhardened -z lazy" should
> produce the same warning. But we don't detect this combination, so
> this patch fixes it. I also renamed a variable to better reflect its
> purpose.
>
> Also don't check warn_hardened in process_command, since it's always
> true there.
>
> Also tweak wording in the manual as Jon Wakely suggested on IRC.
>
> PR driver/117739
>
> gcc/ChangeLog:
>
> * doc/invoke.texi: Tweak wording for -Whardened.
> * gcc.cc (driver_handle_option): If -z lazy or -z norelro was
> specified, don't enable linker hardening.
> (process_command): Don't check warn_hardened.
>
> gcc/testsuite/ChangeLog:
>
> * c-c++-common/fhardened-16.c: New test.
> * c-c++-common/fhardened-17.c: New test.
> * c-c++-common/fhardened-18.c: New test.
> * c-c++-common/fhardened-19.c: New test.
> * c-c++-common/fhardened-20.c: New test.
> * c-c++-common/fhardened-21.c: New test.
> ---
> gcc/doc/invoke.texi | 4 ++--
> gcc/gcc.cc| 20 ++--
> gcc/testsuite/c-c++-common/fhardened-16.c | 5 +
> gcc/testsuite/c-c++-common/fhardened-17.c | 5 +
> gcc/testsuite/c-c++-common/fhardened-18.c | 5 +
> gcc/testsuite/c-c++-common/fhardened-19.c | 5 +
> gcc/testsuite/c-c++-common/fhardened-20.c | 5 +
> gcc/testsuite/c-c++-common/fhardened-21.c | 5 +
> 8 files changed, 46 insertions(+), 8 deletions(-)
> create mode 100644 gcc/testsuite/c-c++-common/fhardened-16.c
> create mode 100644 gcc/testsuite/c-c++-common/fhardened-17.c
> create mode 100644 gcc/testsuite/c-c++-common/fhardened-18.c
> create mode 100644 gcc/testsuite/c-c++-common/fhardened-19.c
> create mode 100644 gcc/testsuite/c-c++-common/fhardened-20.c
> create mode 100644 gcc/testsuite/c-c++-common/fhardened-21.c
>
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 346ac1369b8..371f723539c 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -7012,8 +7012,8 @@ This warning is enabled by @option{-Wall}.
> Warn when @option{-fhardened} did not enable an option from its set (for
> which see @option{-fhardened}). For instance, using @option{-fhardened}
> and @option{-fstack-protector} at the same time on the command line causes
> -@option{-Whardened} to warn because @option{-fstack-protector-strong} is
> -not enabled by @option{-fhardened}.
> +@option{-Whardened} to warn because @option{-fstack-protector-strong} will
> +not be enabled by @option{-fhardened}.
>
> This warning is enabled by default and has effect only when
> @option{-fhardened}
> is enabled.
> diff --git a/gcc/gcc.cc b/gcc/gcc.cc
> index 92c92996401..d2718d263bb 100644
> --- a/gcc/gcc.cc
> +++ b/gcc/gcc.cc
> @@ -305,9 +305,10 @@ static size_t dumpdir_length = 0;
> driver added to dumpdir after dumpbase or linker output name. */
> static bool dumpdir_trailing_dash_added = false;
>
> -/* True if -r, -shared, -pie, or -no-pie were specified on the command
> - line. */
> -static bool any_link_options_p;
> +/* True if -r, -shared, -pie, -no-pie, -z lazy, or -z norelro were
> + specified on the command line, and therefore -fhardened should not
> + add -z now/relro. */
> +static bool avoid_linker_hardening_p;
>
> /* True if -static was specified on the command line. */
> static bool static_p;
> @@ -4434,10 +4435,17 @@ driver_handle_option (struct gcc_options *opts,
> }
> /* Record the part after the last comma. */
> add_infile (arg + prev, "*");
> + if (strcmp (arg, "-z,lazy") == 0 || strcmp (arg, "-z,norelro") ==
> 0)
> + avoid_linker_hardening_p = true;
>}
>do_save = false;
>break;
>
> +case OPT_z:
> + if (strcmp (arg, "lazy") == 0 || strcmp (arg, "norelro") == 0)
> + avoid_linker_hardening_p = true;
> + break;
> +
> case OPT_Xlinker:
>add_infile (arg, "*");
>do_save = false;
> @@ -4642,7 +4650,7 @@ driver_handle_option (struct gcc_options *opts,
> case OPT_r:
> case OPT_shared:
> case OPT_no_pie:
> - any_link_options_p = true;
> + avoid_linker_hardening_p = true;
>break;
>
> case OPT_static:
> @@ -5026,7 +5034,7 @@ process_command (unsigned int decoded_options_count,
>/* TODO: check if -static -pie works and maybe u
Re: [PATCH] driver: -fhardened and -z lazy/-z norelro [PR117739]
On Thu, 28 Nov 2024 at 15:12, Marek Polacek wrote:
>
> On Thu, Nov 28, 2024 at 11:27:32AM +, Dimitri John Ledkov wrote:
> > Did bootstrap with gcc-14 (clean cherrypick, minor offsets).
> > Built and tested on arm64 & x86_64.
> > It resolved the reported problem.
> > Thank you for this patch.
>
> Thanks a lot for testing it!
Is this awaiting code-review from other developers still?
Anything else I can test to help with the review of this code?
>
> > On Tue, 26 Nov 2024, 22:37 Marek Polacek, wrote:
> >
> > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > >
> > > -- >8 --
> > > As the manual states, using "-fhardened -fstack-protector" will produce
> > > a warning because -fhardened wants to enable -fstack-protector-strong,
> > > but it can't since it's been overriden by the weaker -fstack-protector.
> > >
> > > -fhardened also attempts to enable -Wl,-z,relro,-z,now. By the same
> > > logic as above, "-fhardened -z norelro" or "-fhardened -z lazy" should
> > > produce the same warning. But we don't detect this combination, so
> > > this patch fixes it. I also renamed a variable to better reflect its
> > > purpose.
> > >
> > > Also don't check warn_hardened in process_command, since it's always
> > > true there.
> > >
> > > Also tweak wording in the manual as Jon Wakely suggested on IRC.
> > >
> > > PR driver/117739
> > >
> > > gcc/ChangeLog:
> > >
> > > * doc/invoke.texi: Tweak wording for -Whardened.
> > > * gcc.cc (driver_handle_option): If -z lazy or -z norelro was
> > > specified, don't enable linker hardening.
> > > (process_command): Don't check warn_hardened.
> > >
> > > gcc/testsuite/ChangeLog:
> > >
> > > * c-c++-common/fhardened-16.c: New test.
> > > * c-c++-common/fhardened-17.c: New test.
> > > * c-c++-common/fhardened-18.c: New test.
> > > * c-c++-common/fhardened-19.c: New test.
> > > * c-c++-common/fhardened-20.c: New test.
> > > * c-c++-common/fhardened-21.c: New test.
> > > ---
> > > gcc/doc/invoke.texi | 4 ++--
> > > gcc/gcc.cc| 20 ++--
> > > gcc/testsuite/c-c++-common/fhardened-16.c | 5 +
> > > gcc/testsuite/c-c++-common/fhardened-17.c | 5 +
> > > gcc/testsuite/c-c++-common/fhardened-18.c | 5 +
> > > gcc/testsuite/c-c++-common/fhardened-19.c | 5 +
> > > gcc/testsuite/c-c++-common/fhardened-20.c | 5 +
> > > gcc/testsuite/c-c++-common/fhardened-21.c | 5 +
> > > 8 files changed, 46 insertions(+), 8 deletions(-)
> > > create mode 100644 gcc/testsuite/c-c++-common/fhardened-16.c
> > > create mode 100644 gcc/testsuite/c-c++-common/fhardened-17.c
> > > create mode 100644 gcc/testsuite/c-c++-common/fhardened-18.c
> > > create mode 100644 gcc/testsuite/c-c++-common/fhardened-19.c
> > > create mode 100644 gcc/testsuite/c-c++-common/fhardened-20.c
> > > create mode 100644 gcc/testsuite/c-c++-common/fhardened-21.c
> > >
> > > diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> > > index 346ac1369b8..371f723539c 100644
> > > --- a/gcc/doc/invoke.texi
> > > +++ b/gcc/doc/invoke.texi
> > > @@ -7012,8 +7012,8 @@ This warning is enabled by @option{-Wall}.
> > > Warn when @option{-fhardened} did not enable an option from its set (for
> > > which see @option{-fhardened}). For instance, using @option{-fhardened}
> > > and @option{-fstack-protector} at the same time on the command line
> > > causes
> > > -@option{-Whardened} to warn because @option{-fstack-protector-strong} is
> > > -not enabled by @option{-fhardened}.
> > > +@option{-Whardened} to warn because @option{-fstack-protector-strong}
> > > will
> > > +not be enabled by @option{-fhardened}.
> > >
> > > This warning is enabled by default and has effect only when
> > > @option{-fhardened}
> > > is enabled.
> > > diff --git a/gcc/gcc.cc b/gcc/gcc.cc
> > > index 92c92996401..d2718d263bb 100644
> > > --- a/gcc/gcc.cc
> > > +++ b/gcc/gcc.cc
> > > @@ -305,9 +305,10 @@ static size_t dumpdir_length = 0;
> > > driver added to dumpdir after dumpbase or linker output name. */
> >
[PATCH] doc: Document lack of SAHF support on Apple Rosetta 2 [PR119781]
Apple Rosetta 2 x86-64 emulator is known to not support SAHF
instruction, which otherwise might be generated when targetting
-march=x86-64-v2.
PR target/119781
gcc/ChangeLog:
* doc/invoke.texi: Document lack of SAHF on Apple Rosetta 2.
Signed-off-by: Dimitri John Ledkov
---
gcc/doc/invoke.texi | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 67155eeeda7..0efcef0957b 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -36226,6 +36226,7 @@ Early Intel Pentium 4 CPUs with Intel 64 support,
prior to the introduction of Pentium 4 G1 step in December 2005,
lacked the @code{LAHF} and @code{SAHF} instructions
which are supported by AMD64.
+Apple Rosetta 2 x86-64 emulator is also known to not support this instruction.
These are load and store instructions, respectively, for certain status flags.
In 64-bit mode, the @code{SAHF} instruction is used to optimize @code{fmod},
@code{drem}, and @code{remainder} built-in functions;
--
2.43.0
