How i could save le preprocessor in output file with specific name as x or y ?
I tried the command line :
gcc -E -o pgcd.c x.o
But it don't seem being the solution.
ps: the file doesn't exist before the compilation, i just would save the preprocessor in a file with the name i defined.
Thank you for any help.
gcc -E file.c
will preprocess file.c and write the preprocessed source code to the
standard output (console). So to save the preprocessed output, redirect
the standard output to a file of your choice:
gcc -E file.c > somefile
It is a bad idea for somefile to have an .o extension. GCC and other
tools interpret the .o extension as meaning that the file contains object
code, as output by compilation. Preprocessing file.c does not produce
object code. It just produces preprocessed source code, which you might later compile.
The conventional file extension for preprocessed C source code is .i
(.ii for preprocessed C++ source code). Therefore
gcc -E file.c > file.i
is the appropriate choice.
You will discover that file.i contains preprocessor line-markers, e.g.
# 1 "file.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "<command-line>" 2
# 1 "file.c"
# 1 "/usr/include/stdio.h" 1 3 4
# 27 "/usr/include/stdio.h" 3 4
...
...
If you don't want these line-markers to appear in the output, add the -P
option:
gcc -E -P file.c > file.i
The GCC -save-temps flag can also be used to save the processed file in *.i files (although this differs from -E in that compilation of the files are not halted after the pre-processor stage).
Related
I am trying to preprocess a .h file and produce a new .h file with all of the # preproc directives resolved. I used gcc -E file.c command and I always get this output:
# 1 "file.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "file.c"
Which command should I use to produce a new preprocessed .h file?
From https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html
-P
Inhibit generation of linemarkers in the output from the preprocessor. This might be useful when running the preprocessor on something that is not C code, and will be sent to a program which might be confused by the linemarkers.
Simply use
gcc -E -P file.c
When I preprocess a C++ file like this:
g++ -E source.cpp
the preprocessed file still contains a lot of preprocessor instructions like these:
# 1 "/usr/include/features.h" 1 3 4
# 367 "/usr/include/features.h" 3 4
# 1 "/usr/include/x86_64-linux-gnu/sys/cdefs.h" 1 3 4
I don't need them. How can I get a preprocessed file without these instructions?
You can use the -P option. It prevents GCC from creating these line options:
g++ -E -P source.cpp
Is it possible to achive something like this with gcc -E?
src.c:
z
#define FOO bar
z
actual preprocess result:
# 1 "src.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "src.c"
z
z
desired preprocess result:
# 1 "src.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "src.c"
z
/* #define FOO bar */
z
It can't be done directly, but if you really wanted this, you could pass the -dD option to cpp (via the gcc driver it might look like -Wp,-dD; then further process the output to turn the #defines into comments.
-dD tells the preprocessor to keep the #define directives in the resulting output.
If you want to keep the defines as comments maybe you can study MCPP manual, I sort of remember there is an option for this.
At least -C preserves the comments, and -K is described as "embed macro annotation into comments".
https://linux.die.net/man/1/mcpp
What does "macro annotations embedding in comments" mean in mcpp?
If that doesn't work you'll have to make a parser. either use clang as a library and iterate on preprocessor tokens. Or do your own with AntlR (there are many ready to use C grammars)
There's now gdb and binutils support for separating debug info from the binaries to be debugged. Docs describing this can be found in:
gdb: separate debug files
objcopy --add-gnu-debuglink, --only-keep-debug
ld --build-id
After a bit of experimenting, I'm able to get gdb (7.6) to find the debug info using either the build-id and debug-link methods. Here's two gdb fragments that show the debugger finding the debug info in the non-standard locations, using the build-id and debug-link methods respectively:
(gdb) set debug-file-directory .
(gdb) file uWithBuildId
Reading symbols from /home/peeterj/build-id/uWithBuildId...Reading symbols from /home/peeterj/build-id/.build-id/2d/41caac1bcbeb65255abc3f35624cf9ed37791a.debug...done.
Reading symbols from /home/peeterj/build-id/uWithDebugLink...Reading symbols from /home/peeterj/build-id/uWithDebugLink.debug...done.
To create the debug info files I've used objcopy and strip. I've included details of such commands below for reference.
However, the reason I'm looking at this at all is with the hope of being able to build all of our product code with -g. Currently this breaks the debugger if we try since our shared-lib is too big with relocation truncated to fit messages like:
/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../lib64/crtn.o:(.debug_aranges+0x6): relocation truncated to fit: R_X86_64_32 against `.debug_info'
(and subsequent link failure)
Does anybody know of a way to do one of:
Generate a standalone file containing all the debug info from the sources that contribute to the binary (i.e all the .o's and .a's that end up in the ld command that generates the binary).
Or, instruct ld to link without including this debug info in the binary itself, and generate a standalone debug file that can be identified with a build-id or debug-link? I don't see anything in the docs for a single pass method to do this with ld, but the ld docs are big and perhaps I missed it.
Some way to deal with the truncation error above (such a method would allow either the build-id or debug-link methods to work).
sample commands to generate separate debug files for an executable
Here's a sample command line sequence using both the --build-id and --add-gnu-debuglink methods:
g++ -g -c -o u.o u.cpp
g++ -o uWithBuildId -Wl,--build-id u.o
g++ -o uWithDebugLink u.o
copyDebugAndStrip uWithBuildId
objcopy --only-keep-debug uWithDebugLink uWithDebugLink.debug
objcopy --add-gnu-debuglink=uWithDebugLink.debug uWithDebugLink
strip -g uWithDebugLink
where copyDebugAndStrip is the following perl code:
#!/usr/bin/perl
my $binary = $ARGV[0] ;
my #p = `objdump --section .note.gnu.build-id -s $binary | tail -2` ;
foreach (#p)
{
chomp ;
s/^ *[\da-f]+ *// ;
s/ .*// ;
s/ //g ;
}
my $buildid = "$p[0]$p[1]" ;
$buildid =~ /^(..)(.*)/ ;
my ($d, $r) = ($1, $2) ;
print "build-id for '$binary': $buildid\n" ;
my $cmd =
"mkdir -p .build-id/$d
rm -f .build-id/$d/$r.debug
objcopy --only-keep-debug $binary .build-id/$d/$r.debug
strip -g $binary
" ;
print $cmd ;
system $cmd ;
Initially it appeared that the binutils gold linker was capable of building large -g shared libs, providing a solution for (3) above, however, it turns out that is because of a lack of error checking.
On the other hand it looks like work on (1) and (2) is in available if a bleeding edge toolchain is used, part of the fission dwarf/binutils/gcc work described here:
http://gcc.gnu.org/ml/gcc/2011-10/msg00326.html
http://gcc.gnu.org/wiki/DebugFission
This fission work was mentioned in discussion of a bugzilla report on this relocation truncation error:
http://sourceware.org/bugzilla/show_bug.cgi?id=15444
An example of the use of this split debug files is:
g++ -gsplit-dwarf -gdwarf-4 -c -o main.o main.cpp
gcc -gsplit-dwarf -gdwarf-4 -c -o d1/t1.o d1/t1.c
g++ -gsplit-dwarf -gdwarf-4 -c -o d2/t2.o d2/t2.cpp
gcc -Wl,--index-gdb main.o d1/t1.o d2/t2.o -o main
where gcc/g++ are version 4.8, the binutils trunk (cvs -z 9 -d :pserver:anoncvs#sourceware.org:/cvs/src co binutils) has been used configured with --enable-gold=default, and finally using gdb version 7.6 which can read the split debug info.
Joining gcc in the party, the intel (version 16) compiler supports -gsplit-dwarf. The intel compiler documents that binutils-2.24+,gdb-7.6.1+ are required. The clang compiler codebase has some split dwarf support, but I don't know what state that support is in.
I had similar issue with linker when compiling with g++ (v6.3.0) + gold linker (v2.27) + “-g” parameter.
staticlib.a(sharedlib.o):(.debug_loc+0x1d38): relocation truncated to fit: R_X86_64_32 against `.debug_info'
staticlib.a(sharedlib.o):(.debug_loc+0x6c8c): additional relocation overflows omitted from the output
collect2: error: ld returned 1 exit status
gmake: *** [exec_file] Error 1
287.760u 35.837s 7:30.37 71.8% 0+0k 17217048+14932696io 0pf+0w
Adding the parameter "-fdebug-types-section" fixed this issue.
More details at: https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
How can I use gcc to expand macros in files containing (for example) python/php/perl code?
Having a file containing:
#define foo very important stuff
#define feast Christmas
I should take care of some foo for feast.
I have tried to use:
$ gcc -x c++ -E - < text.txt > output.txt
but it displays this:
$ cat output.txt
# 1 "<stdin>"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "<stdin>"
I should take care of some very important stuff for Christmas.
How to avoid gcc to add those comments and (if possible) the extra newlines?
You should be aware of this warning from the online docs for the GNU C preprocessor
The C preprocessor is intended to be
used only with C, C++, and Objective-C
source code. In the past, it has been
abused as a general text processor. It
will choke on input which does not
obey C's lexical rules. For example,
apostrophes will be interpreted as the
beginning of character constants, and
cause errors. Also, you cannot rely on
it preserving characteristics of the
input which are not significant to
C-family languages. If a Makefile is
preprocessed, all the hard tabs will
be removed, and the Makefile will not
work.
The '#' lines in the output could be the least of your problems.
You might do better with a different tool, such as m4.
I do not know if there is a specific option for gcc.
You can postprocess with a grep
$ gcc -x c++ -E - < text.txt | grep -v '^#' > output.txt