I know "gcc -E main.c" option gives all the values pre-processed output. Is there a way to just expand the user defined macros?
For example
#define MACRO(z) z+z
c = a + (MACRO(z))
When I use this hypothetical gcc option, I should see:
c = a + (z+z)
I do not want any other system-defined MACRO's to be expanded. Is there an option in GCC?
Effectively what you want to do is to have the preprocessor ignore errors opening include files. I think there is a compiler with such a feature, but GCC isn't it. (Or maybe I'm confusing it with the GCC feature to ignore missing include files when generating dependency files.)
However what you can do instead is to create a shadow directory of empty files matching all the names and sub-directories for the system headers. You can then use the -nostdinc (to ignore the system include directories) and -I option (to point at your new shadow directory).
The shadow directory can be created with something like:
mkdir $HOME/tmp/emptystdinc
cd $HOME/tmp/emptystdinc
find /usr/include -type d -print | sed 's|/usr/include|.|' | xargs mkdir -p
find /usr/include -type f -print | sed 's|/usr/include|.|' | xargs touch
Now see what your post-processed code looks like:
cc -E -nostdinc -I$HOME/tmp/emptystdinc test.c
Good luck! This works fine for me!
Quoting from cpp man page:
-undef
Do not predefine any system-specific or GCC-specific macros. The standard predefined macros remain defined.
This means that macros such as __FILE__ or __LINE__ will be expanded, but this may be sufficient for your needs. You can also undefine these standard predefined macros using -U. The full list can be found here.
Related
In my makefile, I added parameters to linker flags as a variable BOOTLOAD
LDFLAGS += -Wl,--section-start=.bootloader=$(BOOTLOAD)
If i write BOOTLOAD = 0x3800 in makefile everything is working fine.
But i want to pass this variable from C code, so i tried to define it like #define BOOTLOAD 0x3800. But the linker cannot find it.
How should i pass BOOTLOAD from C file?
Instead of "passing" the macro from a C source file (which is possible but not easy), you could instead ask the preprocessor to define the macro when compiling with the -D option:
gcc -DBOOTLOAD=$(BOOTLOAD) -c source_file.c
I recommend you check the GCC preprocessor command line option reference for more information about the -D option.
It is possible to search a specific source file to the macro definition and then set a makefile variable to the extracted value, but it's easier to do it the other way around as shown above.
It seems you have to grep BOOTLOAD from the source code in your makefile as follows:
BOOTLOAD = $(shell grep '#\s*define\s\+BOOTLOAD' YOUR_SOURCE_FILE | awk 'print $3')
LDFLAGS += -Wl,--section-start=.bootloader=$(BOOTLOAD)
Can I use Preprocessor Directives in .ld file?
I need to to use one of two sets of .ld file and wants to let Build engine deside that using macro, Can I do that?
Yes, you can. You need to run preprocessor manually for your linker script, like this:
in="your_linker_script.ld"
out="generated_script.ld"
cflags=-Iinclude/
gcc -E -P -x c $cflags $in >$out
Flags:
-E specifies GCC to only run preprocessor
-P prevents preprocessor from generating linemarkers (#line directives)
-x c tells GCC to treat your linker script as C source file (it's needed to run GCC with your LD script)
Or you can simply use cpp tool, which is actually C preprocessor.
After this you will be able to use generated linker script to build your program (e.g. in Makefile).
Example
Here is how I solved this problem in my project:
Here is my linker script uses preprocessor (#include directive and CONFIG_TEXT_BASE constant). Excerpt:
#include <config.h>
. = CONFIG_TEXT_BASE;
Here is script to generate preprocessed linker script. Excerpt:
gcc -E -P -x c -Iinclude $cflags $in >>$out
Here is my Makefile, it's generating preprocessed linker script at $(LDS_GEN) target (line 53) and the this generated script is being used to build result binary (line 42). Excerpt:
$(LDS_GEN): $(LDS)
build/gen-lds.sh $(LDS) $(LDS_GEN) $(CFLAGS)
$(APP).bin: $(OBJS) $(LDS_GEN)
$(LD) $(OBJS) -T $(LDS_GEN) -o $(APP).elf
Small update after long time. This way of pre-processing works until the memory file does not contain lines that are fooling the pre-processor. E.g.:
"KEEP(*path/*.o(.rodata .rodata*))"
The "/*" after path is considered comment start (the line contains what is considered a C multi-line comment start and not a match pattern).
This line is valid for the linker but it is considered comment and the output from C pre-processor will remove everything till a supposed closing comment is found:
"KEEP(*path"
The resulting file is clearly invalid for the linker. I have no solution at the moment.
As a simplification of Sam's answer, I added the below to my makefile and away we go :)
PRE_LD_FILE = $(PROG_NAME).ld
LD_FILE = $(PROG_NAME)_generated.ld
$(LD_FILE) : $(PRE_LD_FILE)
cpp $(PRE_LD_FILE) | grep -v '^#' >>$(LD_FILE)
I'm compiling a kernel module and I'm including <asm/unistd.h>, but I'm not sure if the compiler is using the unistd.h from /usr/includes/ (wrong) or the one from /usr/src/kernel-3.x.x/arch/x86/includes/ (right).
My question is: How can I check which one of those two is the compiler using?
And also, is there a way to force the file from the kernel headers instead of the one from /usr/include?
cpp code.c | grep unistd.h
or
gcc -E code.c | grep unistd.h
To answer the second part of your question:
And also, is there a way to force the file from the kernel headers instead of the one from /usr/include?
You can pass the -nostdinc option to gcc:
"Do not search the standard system directories for header files. Only the directories you have specified with -I options (and the directory of the current file, if appropriate) are searched."
GCC: Options Controlling the Preprocessor
Company policy dictates that every function in C source code has a prototype. I inherited a project with its own make system (so I cannot test it on gcc or Visual Studio) and found that one of the files has some static functions declared without prototypes. Is there a way (not necessarily with a compiler) to list all functions without prototypes in all .c files?
gcc has an option to warn you about this:
gcc -Wmissing-prototypes
You can turn this warning into an error to stop compilation and force people to fix it:
gcc -Werror=missing-prototypes
If you just want to list it you can compile with the gcc option -Wmissing-prototypes and grep for no previous prototype for in the log.
Update based on edit:
Since you now mention that you can't use gcc, you'll have to find a similar option for your current compiler. Most compilers have such an option. Start with the man page or the built in help output.
ctags can do that!
--c-kinds=p generates the list of all function prototypes
--c-kinds=f generates the list of all function definitions
Now you just need to compare those.
diff -u <(ctags -R -x --sort=yes --c-kinds=f | cut -d' ' -f1) <(ctags -R -x --sort=yes --c-kinds=p | cut -d' ' -f1) | sed -n 's/^-//p'
Is it possible to look at a c/c++ file before preprocessing? Or rather after just a half-hearted pre-processing? Basically there is a
#define <commonly_used_word> 0
in a third party library header and I want to figure out where it is. So basically, I just want the compiler to include all the headers but not the the preprocessor as such.
Your original source file is file before preprocessing.
It sounds like you want your #include directives processed, yet you want to keep macros non-substituted. Both actions are carried out by the preprocessor.
In general case it is impossible, since in C and C++ it is legal to use macros as include file names, as in
#define INCLUDE_FILE "stdio.h"
#include INCLUDE_FILE
Achieving what you want would require a preprocessor specifically designed to satisfy your request. I, for one, don't know of any such preprocessor implementation.
If you want to find where a specific macro is defined, you might try the following trick: define your own macro with the same name before including any headers, and start compilation. The compiler (the preprocessor) should complain about macro redefinition when it encounters the library definition of the same macro and point out its location to you.
There are GCC-specific -M and -MM options:
To list absolute paths of include files, use -M
Instead of outputting the result of preprocessing, output a rule
suitable for make describing the dependencies of the main source file.
The preprocessor outputs one make rule containing the object file name
for that source file, a colon, and the names of all the included
files, including those coming from -include or -imacros command line
options. gcc -M test.c
If you dont want the system includes like
#include <stdio.h>,
then use -MM Like -M but do not mention header files that are found in
system header directories, nor header files that are included,
directly or indirectly, from such a header. gcc -MM test.c
That could significantly narrow down the search area.
http://www.math-linux.com/spip.php?article263
You can tell cpp to generate the list of included files using -M option:
$ cpp -M a.c
a.o: a.c /usr/include/stdio.h /usr/include/features.h \
/usr/include/sys/cdefs.h /usr/include/bits/wordsize.h \
/usr/include/gnu/stubs.h /usr/include/gnu/stubs-64.h \
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/include/stddef.h \
/usr/include/bits/types.h /usr/include/bits/typesizes.h \
/usr/include/libio.h /usr/include/_G_config.h /usr/include/wchar.h \
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/include/stdarg.h \
/usr/include/bits/stdio_lim.h /usr/include/bits/sys_errlist.h
It gives you a Makefile rule format but you could ignore that and use with any other command.
For example, you can grep for the symbol (here I'm ignoring stderr because of \ and a.o: not being a real file names -- laziness):
$ grep '#\s*define\s*BUFSIZ' $(cpp -M a.c) 2>/dev/null
/usr/include/stdio.h:# define BUFSIZ _IO_BUFSIZ
You can also use a program like ctags to find the symbol for you:
$ ctags $(cpp -M a.c)
...
$ grep BUFSIZ tags
BUFSIZ /usr/include/stdio.h 128;" d
If you know which header files contain the definition you're looking for, e.g by using find and grep as suggested, you may be able to pinpoint which one is affecting the current source file by getting gcc to print the header inclusion tree. As described in gcc's documentation, you can achieve this by using the -H option, possibly combined with -MG to eliminate normal processing.