Do note this is different from
Get the compiler options from a compiled executable? which I did go through in detail.
Although -frecord-gcc-switches is great, it only captures the command line arguments.
For example, I am not interested in capturing -O2 which is usually passed in command line. I am more curious about recording all the flags like -fauto-inc-dec which are enabled by -O2.
(In contrast to the link above, do note that I have access to the source, the compiler and the build infrastructure. I just want to capture the flags during compilation. Not picky about any specific gcc version)
You can try -fverbose-asm. That dumps the optimisation options used in a comment at the top of the assembly file.
Related
I am learning to write ARM code using the GCC toolchain. I've run into a few GCC options that I cannot find documentation for. Could someone please help explain what they do?
-specs=nosys.specs
-specs=nano.specs
-specs=rdimon.specs
-lnosys
How do -specs=nosys.specs and -lnosys relate? Do you use them together, or are they exclusive of each other, or something else?
And nano, I've gathered to imply using the newlib-nano library. I've seen this used in conjunction with -lm and -lc. Does this just give you the standard libc and libm functions?
What does rdimon stand for? I understand it is for "semihosting", which means using the host IO somehow. Does this mean I can printf to the host console? I can find no documentation on how to actually use this.
If there is a source of truth for all of this somewhere that I haven't found, please let me know.
Thanks for any help on clarifying.
Gcc uses specs-strings, which control which subprocesses to run and what parameters it shall pass to them. The behavior defined by the spec-strings can be overridden using spec-files, whose purpose and syntax is documented here: https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html
Looking at these spec files in the lib folder of the gcc tool chain (e.g. /usr/lib/arm-none-eabi/lib) we can see that the mentioned spec files define which standard library is to be used by the linker.
For example, nosys.specs just defines that system calls should be implemented as stubs that return errors when called (-lnosys). The choice of libc in this case depends on whether nano should be used. With %G the libgcc spec-string is processed, which defines the parameters passed to the linker.
nosys.specs:
%rename link_gcc_c_sequence nosys_link_gcc_c_sequence
*nosys_libgloss:
-lnosys
*nosys_libc:
%{!specs=nano.specs:-lc} %{specs=nano.specs:-lc_nano}
*link_gcc_c_sequence:
%(nosys_link_gcc_c_sequence) --start-group %G %(nosys_libc) %(nosys_libgloss) --end-group
nano.specs defines the system include path and library parameters to use newlib-nano. The spec file contains replacements for -lc and others to nano equivalents, e.g. -lc_nano. So using it in conjunction with these will make gcc still pass nano libaries to the linker.
Using rdimon.specs, -lrdimon is passed as the libgloss part of the standard library. This basically means that you can use system calls (and also printf), but this relies on a debugger being attached, and the CPU may crash if no debugger is present.
I work with a very long Fortran code full of preprocessor (#if) conditionals, Is there any way to compile it and get a source file only with the fraction of the code where conditions are satisfied?
As mentioned by chw21, you can run the preprocessor directly. Either the cpp (with the right flags) or the fpp command, depending on your compiler.
Because you can be unsure about the right flags, you can also let the compiler do that for you. In GCC (gfortran) it is the -E flag, which will force the compiler to stop after preprocessing. You must redirect standard output to a file because the preprocessed code is returned to standard output.
I'm working on setting up autotools for a large code base that was once just a bash script compile and later just hand written Makefiles.
We have a set of files that require that compiler optimizations be turned off. These files are already in their own subdirectory, so they will have their own Makefile.am.
What's the proper way to drop any existing compiler optimizations and force a -O0 flag on the compiler for these specific files?
I went with Brett Hale's comment to use subpackages. I was able to insert
: ${CFLAGS="-O0"}
before AC_PROG_CC, which sets the appropriate optimization. The other solutions do not work, since the -g -O2 was getting added very last. You can never get another -O variable after it.
You don't have to remove existing optimizations: the last value of -O on the compiler invocation will be used, so it's good enough to just add -O0 at the end.
This is not directly supported by automake, but there's a trick you can use defined in the documentation.
Otherwise if you know you'll only ever invoke your makefile with GNU make you can play other tricks that are GNU make specific; you may have to disable automake warnings about non-portable content.
In short, I have the most recent version of MinGW and I am attempting to pass options into the linker and the like.
For example, I wanted to change the stack size by:
gcc -Wl,--stack,[new size in bytes]
But it recognized neither -Wl nor --stack. And that applies for the other options too.
I'm able to compile my programs all well in good, it just seems as though I cannot use the various gcc options.
Is this an issue with MinGW, or am I overlooking something more?
I just confirmed in the documentation about passing arguments to linker, that you cannot have a space before the number, so it should be:
gcc -Wl,--stack,[new size in bytes]
Commas are changed into spaces, but a real space makes the next option gcc option, not linker option.
Is there a way to change the specs file so that it will pass -march=native if nothing is specified in command line?
Related things in the default specs file is:
*cc1:
%(cc1_cpu)
*cc1_cpu:
%{march=native:%>march=native %:local_cpu_detect(arch) %{!mtune=*:%>mtune=native %:local_cpu_detect(tune)}} %{mtune=native:%>mtune=native %:local_cpu_detect(tune)}
I am not sure how specs works. Simply specifying -march=native before or after %(cc1_cpu) doesn't work. However, this line does take effect because GCC will report error if I put -something_wierd instead of -march=native.
Another thing I noticed is if I put %{march=i386:-something_wierd} before %(cc1_cpu), gcc reports error so looks like -march=i386 is always passed in if nothing is specified, so is there a way to distinguish between nothing specified and -march=i386 in specs file?
BTW, what does %> do? Seems like it is not specified in the documentation.
I am using MinGW's gcc-4.6.2.
Referring to your last question: The gcc 4.6.1 sources (gcc/gcc.c) contain the following comment on %>:
%>S Similar to "%<S", but keep it in the GCC command line.
For the sake of completeness following the comment for %< form the same file:
%<S remove all occurrences of -S from the command line.
Note - this command is position dependent. % commands in the
spec string before this one will see -S, % commands in the
spec string after this one will not.
To answer the first question in short: yes, but ....
... the only generic solution I found has the significant drawback that the -march option will be ignored, so every build is done as if -march=native had been specified. Anyhow there is a workaround to that.
1 The solution (without workaround)
Create a specs-file called let's say specs.nativealways containing:
*cc1_cpu:
%<march=* -march=native %>march=native %:local_cpu_detect(arch) %{!mtune=*:%>mtune=native %:local_cpu_detect(tune)} %{mtune=native:%>mtune=native %:local_cpu_detect(tune)}
When using the specs-file (for example by invoking gcc with the option -specs=specs.nativealways) the build will be done as if -march=native was specified (with the mentioned drawback that any occurrence of option -march=<arch> would have simply been ignored).
2 The workaround
To still by able to override the newly configured default behavior one can use a modified version of the specs-file described above, introducing a new option called -myarch using the same syntax as -march (except for -myarch=native, which won't work, which does not metter as native now is the default).
The modfied specs-file looks like this:
*cc1_cpu:
%<march=* %{myarch=*:%<myarch* -march=%* ; :-march=native %>march=native %:local_cpu_detect(arch) %{!mtune=*:%>mtune=native %:local_cpu_detect(tune)}} %{mtune=native:%>mtune=native %:local_cpu_detect(tune)}
PS: This has been tested with with gcc 4.6.2 on Linux, but should work on MinGW.
While not a direct answer to your question, you can reach a very similar effect by defining CFLAGS and CXXFLAGS in your shell's initialization file. 99% of the Makefiles are sufficiently standard to pick up the environment values and pass the flags to gcc.
*cc1_cpu:
+ %{!march*:-march=native}