I'm interested in expanding the macros of a single Linux kernel file (arch/x86/kernel/nmi.c).
I know that normally one can use gcc -E to expand the macros.
However since the file is part of the Linux kernel, many options need to be passed to gcc. I'm then trying to modify the kernel Makefile to pass the -E flag.
I'm currently modifying the /arch/x86/kernel/Makefile that is the one use to compile nmi.c and call this particular sub-Makefile by
make M=arch/x86/kernel
I found out that extra gcc flags can be passed by using CFLAGS_nmi.o.
However adding
CFLAGS_nmi.o := -E
to the Makefile does not have the expected effect
This is the output after modifying the Makefile
~/git/linux$ make M=arch/x86/kernel
CC arch/x86/kernel/nmi.o
AR arch/x86/kernel/built-in.a
Building modules, stage 2.
MODPOST 3 modules
I would expect the expanded code after the "CC arch/x86/kernel/nmi.o" line.
I also tried "CFLAGS_nmi.o := -E > nmi.out" to try to redirect the output, but the generated file is empty.
Adding
CFLAGS_nmi.o := -save-temps=obj
did the trick. Thanks!
Related
I have an AVR8 GCC application that can be built with a standard makefile. Because some folks who want to build the application don't want to set up make and such (or have trouble doing so), I also have figured out how to set the project up so it can be compiled from the Arduino IDE as well.
All is working.
But, I normally set some items in the makefile, like the version number and such, but creating the VERSION string in the makefile and passing it as a define into each source file compilation. But, when run from the Arduino IDE, that step is obviously not occurring. So, I have to create a second #define in the Arduino sketch stub to recreate the define.
This means when I update the version, I need to do so in 2 places, in the makefile and in the source file.
The easy option is to simply move the VERSION creation to the source file, where both can use it. And, I'm OK doing that, but
The makefile actually needs the version information, both to create the right filename (think app_v1.2.3.4.bin) and embed the version number into the bin file since it is used by the boot-loader (if requested) to ensure the version the boot-loader flashes is newer than the one already in FLASH. So, if I move the VERSION, RELEASE, MODIFICATION, etc. defines into the C code, I need to find a way to pull them back into the makefile.
I tried using the file read operations in the makefile, but they seem to ignore:
#define VERSION 0
with the prefaced '#' char.
I see there's some options to run sed/awk/etc, in bash, but I don't want to make too many assumptions on the environment, and the makefile currently runs on Windows as well as Unix/Linux without any differences.
I tried a few stack overflow examples, but nothing seems to yield those 4 numbers from any file, .h or otherwise.
I'm OK with creating version.h with just:
#define VERSION 0
#define RELEASE 1
#define MODIFICATION 2
#define FIX 4
If I can read it into the makefile and create the variables I need.
Jim
You may take a look at gmtt which was designed exactly with you use case in mind. In gmtt the following should read and analyze your header file:
include gmtt.mk
# create a 3-column table from the header file. The first column is just the "#define"
VNR_TABLE := 3 $(file < version.h)
# Extract the values from the table: select column 3 from VNR_TABLE where column 2 equals a string constant.
# Be careful not to introduce spaces in the compare!
VER := $(call select,3,$(VNR_TABLE),$$(call str-eq,$$2,VERSION))
REL := $(call select,3,$(VNR_TABLE),$$(call str-eq,$$2,RELEASE))
MODF := $(call select,3,$(VNR_TABLE),$$(call str-eq,$$2,MODIFICATION))
FIX := $(call select,3,$(VNR_TABLE),$$(call str-eq,$$2,FIX))
I couldn't test it but I think you get the idea.
PS: using a GNUmake library just means placing the included file alongside the makefile.
I think in this case you can use the ‘file’ function of makefiles.
It allows you to write (with > specifier) or read (with < specifier) to/from files. Then you can trim (with filter-out) your variables inside your makefile.
Source: https://www.gnu.org/software/make/manual/html_node/File-Function.html#File-Function
You can use GNU make's $(shell ...) function to extract the macro expansions. Assuming VERSION is defined in src.c and tokens are delimited by spaces (not tabs):
VERSION := $(shell sed -n -e "s/^\#define VERSION *\(.*\)/\1/p" src.c)
.PHONY: all
all:
#echo VERSION=$(VERSION)
I'm new to Fortran but I'm trying to find a way that I can retrieve information from programs I've written without including them as subprograms within my new file. As of right now I have 4 subroutines within my new file and I would like to instead just be able to input the radius into all 4 and receive their respective outputs.
this is the basic format for my code--- basically I want to show that I need 4 separate programs in order to get all the variables needed for the current programs expression.
So far I've tried to use both the include and call expressions but they weren't able to retrieve the information I needed to bring back into my file and they came up with just "not applicable" answers.
program practicedynamo
implicit none
real:: A,B,C, Radius
real::Bsquared,Vsquared
read*,radius
call programA(radius,A)
call programB(radius,B)
call programC(radius,C)
Vsquared=(1.0/3.0)*B
Bsquared= 4*pi*density*Vsquared
gradient=radius*C
Rvector=Bsquared*Vsquared*gradient
ThetaVector=Rvector*sin(A)
end program practicedynamo
!and then my four subroutines would be placed afterwards
!here is an example of one of my subroutines within my actual code (the version above has been simplified and I've changed the variables)
subroutine testdensity(radius,density)
implicit none
real::radius,x,sunradius,density
if (radius>0.and.radius<=695500000) then
sunradius=695500000
x=radius/sunradius
density=((519*x**4.0)-(1630*x**3.0)+(1844*x*x)-(889*x)+155)
print*," "
density=density*1000
print*,"the density is",density, "kg per meters cubed"
else
print*, "this radius is not an option for the sun"
end if
end subroutine testdensity
You haven't mentioned how you are compiling your code, but here are some general ways to include multiple source files in a single executable. You don't need to include the files, you can just compile them separately and link them together. Writing a Makefile to do this is recommended and you can find plenty of examples on that elsewhere.
To compile multiple files into one executable, you need only list them all when compiling
gfortran -o output programA.f90 programB.f90 programC.90 mainprogram.f90
If you do not want to compile them all together or have to recompile when you build, you can compile individual objects, e.g.
gfortran -c -o programA.o programA.f90
gfortran -c -o programB.o programB.f90
gfortran -c -o programC.o programC.f90
and then link as
gfortran -o output mainprogram.f90 programA.o programB.o programC.o
If you are instead trying to use libraries and want program A-C to be in a standalone library, you can first compile the objects as above, then
ar rcs libABC.a programA.o programB.o programC.o
and then compile your main program as
gfortran -o output mainprogram.f90 libABC.a
If you aren't using modules, you'll be responsible for making sure that your calls to external subroutines match the declared interface in the external file. To be safe and have the compiler catch problems with mismatched arguments you can declare explicit interfaces in your program or put the external code into modules and use those modules in the main program.
I'd like to be able to see which header is actually included when I compile. For example, I have two very different check.h files (one is a linux-header thing, the other from the unit test system).
Is there a setting in gcc or some language command/macro that would show where header files are being included from?
You can use the -E flag.
gcc -E source.c
This will show you the “annotated” preprocessed source, including the absolute paths of headers included using <> and relative paths of headers included using "". Keep in mind that it will be a lot to trudge through, especially if you include a lot of system headers (which in turn include implementation-specific headers etc.).
Using grep, you could filter these results with:
gcc -E source.c | grep '^# 1 '
The # n is an annotation describing the line number of the currently-included file, which is always # 1 at the beginning of a file.
You can try adding -MD to your compilation command. This generates a dependency file (suitable for Make) which will tell you all of the include files that your source code depends on.
This can be added to an existing compile command without fear of breaking the compilation, since it generates the dependency file as a side effect of normal compilation.
Does the gcc output of the object file (C language) vary between compilations? There is no time-specific information, no change in compilation options or the source code. No change in linked libraries, environmental variables either. This is a VxWorks MIPS64 cross compiler, if that helps. I personally think it shouldn't change. But I observe that sometimes randomly, the instructions generated changes. I don't know what's the reason. Can anyone throw some light on this?
How is this built? For example, if I built the very same Linux kernel, it includes a counter that is incremented each build. GCC has options to use profiler information to guide code generation, if the profiling information changes, so will the code.
What did you analyze? The generated assembly, an objdump of object files or the executable? How did you compare the different versions? Are you sure you looked at executable code, not compiler/assembler/linker timestamps?
Did anything change in the environment? New libraries (and header files/declarations/macro definitions!)? New compiler, linker? New kernel (yes, some header files originate with the kernel source and are shipped with it)?
Any changes in environment variables (another user doing the compiling, different machine, different hookup to the net gives a different IP address that makes it's way into the build)?
I'd try tracing the build process in detail (run a build and capture the output in a file, and do so again; compare those).
Completely mystified...
I had a similar problem with g++. Pre 4.3 versions produced exactly the same object files each time. With 4.3 (and later?) some of the mangled symbol names are different for each run - even without -g or other recordings. Perhaps the use a time stamp or random number (I hope not). Obviously some of those symbols make it into the .o symbol table and you get a difference.
Stripping the object file(s) makes them equal again (wrt. binary comparison).
g++ -c file.C ; strip file.o; cmp file.o origfile.o
Why should it vary? It is the same result always. Try this:
for i in `seq 1000`; do gcc 1.c; md5sum a.out; done | sort | uniq | wc -l
The answer is always 1. Replace 1.c and a.out to suit your needs.
The above counts how many different executables are generated by gcc when compiling the same source for 1000 times.
I've found that in at least some environments, the same source may yield a different executable if the source tree for the subsequent build is located in a different directory. Example:
Checkout a pristine copy of your project to dir1. Do a full rebuild from scratch.
Then, with the same user on the same machine, checkout the same exact copy of your source code to dir2 (dir1 != dir2). Do another full rebuild from scratch.
These builds are minutes apart, with no change in the toolchain or any 3rd party libs or code. Binary comparison of source code is the same. However, the executable in dir1 has different md5sum than the executable in dir2.
If I compare the different executables in BeyondCompare's hex editor, the difference is not just some tiny section that could plausibly be a timestamp.
I do get the same executable if I build in dir1, then rebuild again in dir1. Same if I keep building the same source over and over from dir2.
My only guess is that some sort of absolute paths of the include hierarchy are embedded in the executable.
My gcc sometimes produces different code for exactly the same Input. The output object files differ in exactly one byte.
Sometimes this causes linker Errors, because one possible object file is invalid. Recompiling another version usually fixes the linker error.
The gcc Version is 4.3.4 on Suse Linux Enterprise.
The gcc Parameters are:
cc -std=c++0x -Wall -fno-builtin -march=native -g -I<path1> -I<path2> -I<path3> -o obj/file.o -c file.cpp
If someone experiences the same effect, then please let me know.
I have a set of C files to compile using gcc and make. The build process works fine.
I want to know if I can obtain - during compilation - one C file containing all the source code without any preprocessor macro.
One simple was would be to make a file that included all the other source files.
$cat *.c > metafile.c
This would construct such a file, depending on how you set you 'pragma once' and ifndef's this file would probably not be able to compile on its own.
On the other hand, if what you want in a file where all the preprocessor macro's have been unfolded and evaluated, then the answer is to add the following to gcc:
-save-temps
then the file .ii will contain the unfolded and evaluated macros
If you include all files to the gcc compiler at once you could use
gcc -E main.c other.c another.c
This will also include the stdlib functions maybe use -nostdinc
You can't - normally you invoke the compiler to compile just a single source file, resulting in an object file. Later you call the linker on all of the object files to create the executable - it doesn't have the original C source code available.
You can, however, create a separate shell script that calls gcc with the -E option just to preprocess the source files, and then use the cat utility to put all the sources in a single file.
You can use the -save-temps option to get the intermediate outputs. However it will be one output file per source file. Each source file gets compiled separately and represents a compilation unit which can't be mixed up.
You can also use the -E option, however that will only run the preprocessor and not continue compilation.