How could I retrieve the intermediate files generated by the preprocessor, using GNU compiler?
I typically have Fortran sources that I compile with -x f95-cpp-input option for preprocessing, and I would like to retrieve the result. I tested different things, including using the -save-temps option (but the output is not really human-readable) and the -fdump-fortran-original option (that I found already too strongly modified by the compiler to be useful). I had a look in the GNU documentation, but could not find anything more useful.
Any hint would be appreciated!
Just use the -cpp -E and you have the result of the preprocessing in the standard output.
-E Stop after the preprocessing stage; do not run the compiler
proper. The output is in the form of preprocessed source code, which
is sent to the standard output.
Input files that don't require preprocessing are ignored.
(from man gcc)
Related
currently I'd like to debug my includes. To do this I want to get the preprocessed code, but without any system header files - just my own code.
I tried it with flag "-E" and "-nostdinc". But then I get errors that for example <string> is missing. How to disable such preprocessing errors?
How to disable such preprocessing errors?
You could create a set of headers files with names matching the standard library headers. Put those headers in the include directory. Let the files be empty.
Using clang or g++/gcc to print preprocessed code without including files from system paths
I can see two other approaches besides the empty header approach:
Instead of using the full pre-processor of the compiler, write your own pre-processor that only does the subset of processing that you want.
Or, write a post-pre-processor that removes the standard header content from the pre-processed result.
(It's not really an answer - just a "hack")
To solve this I created a text file with all system headers by:
rem my GCC STL-PATH
cd Z:\usr\include\c++\10
dir /b > F:\DummySTL\files.txt
Then I executed the following line of code:
for /f "delims=" %F in (files.txt) do copy nul "%F"
This creates an empty text file for every line in the file.
Now I can call gcc or clang just with:
-isystem"F:\DummySTL"
Using clang or g++/gcc to print preprocessed code without including files from system paths
This is not easily possible with GCC. Read about how to invoke GCC.
But you could get all the preprocessed code using g++ -C -E and use some script (perhaps with GNU gawk) to remove the useless parts.
currently I'd like to debug my includes.
I have the habit of generating all the preprocessed code and then use GNU less to look inside it. Disk space is cheap.
Alternatively, consider writing your own GCC plugin doing what you need.
I am writing a programming language that compiles to C++, and wish to debug using GDB. When I debug the programs, I (of course) see the generated code. Is there a way to hav GDB instead display the source file that created the generated code?
Is there a way to hav GDB instead display the source file that created the generated code?
Sure: you must emit #line directives into your generated C++, and you need to generate already preprocessed source (which you very likely already do) into .ii files. Feeding .ii file into g++ will suppress preprocessing, and g++ will respect any #line directives it finds and emit appropriate source location debug info. Documentation.
I know this is a very basic question but when I compile my c/c++ code with gcc/g++ what exactly is the type of the intermediate output before assembler comes into play to generate the machine code ? Is it something like X86 instructions ?
GCC's processing chain is as follows:
your source code
preprocessed source code (expand macros and includes, strip comments) (-E, .ii)
compile to assembly (-S, .s)
assemble to binary (-c, .o)
link to executable
At each stage I've listed the relevant compiler flags that make the process stop there, as well as the corresponding file suffix.
If you compile with -flto, then object files will be embellished with GIMPLE bytecode, which is a type of low-level intermediate format, the purpose of which is to delay the actual final compilation to the linking stage, which allows for link-time optimizations.
The "compiling" stage proper is the actual heavy lifting part. The preprocessor is essentially a separate, independent tool (although its behaviour is mandated by the C and C++ standards), and the assembler and linker are acutally separate, free-standing tools that basically just implement, respectively, the hardware's binary instruction format and the operating system's loadable executable format.
So, compilation of executable in GCC consists of 4 parts:
1.) Preprocessing (gcc -E main.c > main.i; transforms *.c to *.i)
Does include expansion, processes marcos. Removes comments.
2.) Compilation (gcc -S main.i; transforms *.i to *.s, if successful)
Compiles C-code to Assembler (on target x86 architecture it is x86-assembly, on target x86_64 architecture it is x64-assembly, on target arm architecture it is arm assembly, etc.)
Most of Warnings and Errors happens during this part (e.g. does Error and Warning reporting)
3.) Assembly (as main.s -o main.o; transforms *.i to *.o, again if successful)
Assemblies generated assembler to machine code. Though there are still relative address of procedures, and such.
4.) Linking (gcc main.o)
Replaces relative addresses with absolute addresses. Removes useless text.
Linking errors and warnings during this phase.
And in the end (if successful), we get executable file.
So, to answer your question, the intermediate output you mean is actually so called assembly language - see wiki about that Assembly language wiki.
Here's a graphic representation of the gcc compilation steps by courtesy of redhat magazine:
Contrary to what other answers imply, there's no assembly step - rather, generating assembler code replaces the object code generation; it doesn't make much sense to convert an in-memory representation to a textual one if what you really want is a binary representation.
It must be assembly code. You can get it using -S flag in command line for compilation.
There is no "intermediate output". The first output you get is machine code. (Although you can get C/C++ intermediate output by invoking only the preprocessor with -E.)
GCC tool chain, compiles the program from source code down to machine code. The compiler generates the assembly code which the assembler assembles into the machine code. Here is a good tutorial for beginners.
My code is linking against several other libraries that are also developed at my company, one of these libraries is redefining several values from errno.h, I would like to be able to fix this, however I am having trouble finding the exact file that is redefining these values, I am want to know if there is a way to make the compiler tell me when a file has defined a particular value.
You can probably do it by adding -include errno.h to the command line that builds the library in question. Here's a quick example. I have a C program called "file.c":
#define ESRCH 8
That's it - then I compile with:
cc -c -include errno.h file.c
And presto, a compiler warning:
file.c:1:1: warning: "ESRCH" redefined
In file included from /usr/include/errno.h:23,
from <command-line>:0:
/usr/include/sys/errno.h:84:1: warning: this is the location of the previous definition
That will tell you where your bad definitions are.
Have you tried searching with grep?
If you don't want to search through all your headers for the particular #define, you could use
#undef YOUR_MANIFEST_CONSTANT
after each #include in your source module and then start removing them from the bottom up and see where your definitions come from.
Also, your compiler may tell you that a #define has been redefined. Turn all your warnings on.
With GCC I did something similar with:
g++ input.cc -dD -E > cpp.out
-dD tells cpp to print all defines where they were defined. And in the cpp output there are also markers for the include file names and the line numbers.
It is possible that some environments, I'm thinking IDE's here, have configuration options tied into the "project settings" rather than using a configuration header. If you work with a lot of other developers in a place where this behavior is NOT frowned on then you might also check your tool settings.
Most compilers will tell you where the problem is, you have to look and think about what the diagnostic notification is telling you.
Short of that, grep/findstr on *nix/Windows is your friend.
If that yields nothing then check for tool settings in your build system.
Some IDE's will jump to the correct location if you right click on the usage and select 'go to definition'.
Another option if you're really stuck is a command line option on the compiler. Most compilers have an option to output the assembler they generate when compiling C++ code.
You can view this assembler (which has comments letting you know the relative line number in the C++ source file). You don't have to understand the assembler but you can see what value was used and what files and definitions were included when the compiler ran. Check your compiler's documentation for the exact option to use
In general, I occasionally have a chain of nested macros with a few preprocessor conditional elements in their definitions. These can be painful to debug since it's hard to directly see the actual code being executed.
A while ago I vaguely remember finding a compiler (gcc) flag to expand them, but I had trouble getting this to work in practice.
gcc -E will output the preprocessed source to stdout.
For MSVC users, you can right-click on the file/project, view the settings and change the file properties to output preprocessed source (which typically in the obj directory).
This might not be applicable in your situation, but macros really do hamper debugging and often are overused and avoidable.
Can you replace them with inline functions or otherwise get rid of them all together?
You should probably start moving away form Macros and start using inline and templates.
Macros are an old tool, the right tool sometimes. As a last resort remember printf is your friend (and actually printf isn't that bad a friend when your doing multithreaded stuff)
Debug the dissasembly with the symbols loaded.
gcc -save-temps
will write out a .i (or .ii file for C++) which is the output of the C preprocessor, before it gets handed to the compiler. This can often be enlightening.
GCC and compatible compilers use the -E option to output the preprocessed source to standard out.
gcc -E foo.cpp
Sun Studio also supports this flag:
CC -E foo.cpp
But even better is -xdumpmacros. You can find more information in Suns' docs.