I am trying to compile the source code twice with a MACRO defined & undefined. So for default the macro is undefined & i want to define this macro through arguments from Makefile, like
$(MAKE) -c $(present_dir)/new_dir -DONE_MACRO=1
so i am using this ONE_MACRO in file.h.
how this definition is reflected and knows to preprocessor. Here im using cygmake. How to pass an MACRO as argument to compiler with cygmake tool.
file.h:-
#if ONE_MACRO
#define some_targets
#else
#define other_targets
#endif
So how this ONE_MACRO is defined from make file, im trying to pass macro as argument as below
Makefile:-
MY_TARGET:
$(MAKE) -C $(present_dir)/target_dir -D ONE_MACRO=1 $(MAKECMDGOALS)
Here's an example of how to do what I think you want:
define_test.c:
#include <stdio.h>
#ifndef X
#define X 1
#endif
int
main()
{
printf("X = %d\n", X);
}
Makefile:
X = 1
CPPFLAGS += -DX=$(X)
define_test: FORCE
$(CC) $(CPPFLAGS) define_test.c -o $#
FORCE:
Then to pass a different value for macro X:
make X=2
(This assumes you want the value of the macro to be an integer; if you want the value to be a string, you have to get a bit more tricky with quoting properly.)
You can also add the definition directly to the CPPFLAGS, e.g.:
make CPPFLAGS+=-DX=2
For every compiler there is an environmental variable, which passes the areguments to compiler/linker. while dealing with other than GCC we need to find that environmental variables before usage.
like wise in my case RVCT31_CCOPT is the variable which passes the arguments to compiler while building.
Related
Is there a way to make GCC display the value of some preprocessed value during preprocessing? In particular, if I run the equivalent of:
gcc input.c -E >/dev/null
Is there a way to obtain the actual value of an expanded macro? Consider this example:
#if defined(A)
#define B bar
#else
#define B foo
#endif
#define XSTR(x) STR(x)
#define STR(x) #x
int main() {
#pragma message "B is " XSTR(B)
#error DIE
B a = 2;
return 0;
}
I would like to find out that B is foo in this case.
In my actual setup, I do not have access to the entirely preprocessed file, and I cannot remove the -E flag.
Rationale: I have a complex file setup with lots of syntax errors due to incorrectly defined macros, and the fastest way to debug it would be to use this #pragma/#error combination to find out the actual value, stop compilation, manually fix it, and run GCC again to find out where the next error will occur.
I am trying to allow specifying the location of particular symbols in my output binary without giving up the garbage collection feature of ld. For example: if I have in MyInclude.h
#ifndef MY_INCLUDE_H_
#define MY_INCLUDE_H_
void CalledFunc(void);
void UncalledFunc(void);
#endif
and a main program:
#include "MyInclude.h"
int main(void)
{
CalledFunc();
return 0;
}
compiling with gcc with ffunction-sections -fdata-sections and linking with --gc-sections shows in the map file that .text.UncalledFunc has been removed.
I now have a need where I have to place certain functions in different sections. In this example if UncalledFunc() did happen to be called, I want it to be in a special section. I have a linker parameter file that looks something like:
MEMORY
{
FLASH (rx) : ORIGIN = 0x10000000, LENGTH = 512K
}
SECTIONS
{
.text.myregion ORIGIN(FLASH):
{
*(.text.myregion)
*(.text.myregion*)
} >FLASH
ASSERT ( . <= 0x10010000, "Too much stuff in myregion!")
.text :
{
*(.text)
*(.text*)
} >FLASH
}
And UncalledFunc() and CalledFunc() defined as:
void CalledFunc(void) __attribute__ ((section (".text.myregion")))
{
/* ... */
}
void UncalledFunc(void) __attribute__ ((section (".text.myregion")))
{
/* ... */
}
In this case, it seems the function attribute overrides the per function section parameter sent to GCC. As such since both functions are in the same input section, they both appear in the output image. Is there a way to tell the linker to place UncalledFunc() in .text.myregion if it is called but still remove it if it is not? As shown above, myregion has limited space and it would optimal to not place anything there that wasn't necessary.
The compiler is just doing what it's told; you asked it to put that function in that section, so what else should it do?
The linker then sees all the functions in one section, and so garbage collection is not very helpful.
I've not tried this, but I would imagine that simply assigning different manual names to each function will solve the problem:
void CalledFunc(void) __attribute__ ((section (".text.myregion.CalledFunc")))
{
/* ... */
}
void UncalledFunc(void) __attribute__ ((section (".text.myregion.UncalledFunc")))
{
/* ... */
}
However, if that's a lot of typing (or if you use a macro to apply the attribute), then it might be better like this:
#define STRINGIFY(S) #S
#define TOSTRING(S) STRINGIFY(S)
#define NAME __FILE__ "." TOSTRING(__LINE__)
void CalledFunc(void) __attribute__ ((section (".text.myregion." NAME)))
{
/* ... */
}
That way you can do it with search-and-replace and still have each function have a unique section name. (It is necessary to use the macro because __LINE__ is an integer value, but we need a string here, and the # "stringify" operator is only available inside macros. The apparently pointless levels of indirection cause __LINE__ to be evaluated into the actual line number.)
It might be that the __FUNCTION__ macro works, but I'm not confident given that this is outside the function body.
If you use link time optimization, compiler should be able to remove unused functions, even if you put all of them into common section.
So keep modules (let's say include.c include.h test.c), but build like this:
gcc -c -Os -flto include.c -o include.o
gcc -c -Os -flto test.c -o test.o
gcc -flto -Os test.o include.o -o test
This will probably (depends on actual code) inline used function and remove unused one (unless you use attribute noinline.
Please consider the following
/*utils.h*/
#include <cstdio>
#include <iostream>
//#include some other files, including <string>
//ifndef ... and such macro
extern string configpath;
extern void writelog(string, string);
extern string get_fromfile(string, string);
//end the said macro
then we have
/*utils.cpp*/
//all necessary includes, including <string>
#include "utils.h" //they are in the same folder, as the following main .cpp
void writelog(string msg, string location = "lookinconfigfile")
{
if (location == "lookinconfigfile")
{
get_fromFile(configpath, "logpath");
//the function correctly returns the path to logfile, tested separatly.
}
...
}
string get_formFile(string flpt, string wht)
{...}
then in main.cpp, i include utils.h, and set the configpath to point to a file which holds a path to the logfile.
now g++ -c utils.cpp -std=c++11 produces utils.o
g++ -c main.cpp -std=c++11 produces main.o
before introducing the configpath as a global variable, by explicitly mentioning the configpath, that is, hard coding it to each occurrence, i was able to do this:
g++ main.o -o main
and that would generate main as an executable which would behave as expected.
But now i get this:
main.o: In function `writelog(std::string, std::string)':
main.cpp:(.text+0x2ce): undefined reference to `configpath
Also, if i keep the definition of get_fromFile in utils.cpp _after_ writelog, despite the prototype in utils.h, i get that get_fromFile is not defined.
where do i search looking for solutions?
edit: as user2079303 suggested, yes, it is utils.h, not utils.cpp, thank you.
edit2: as bobah mentioned, i actually have the cases correct in my code, just mistyped here. sorry.
You need to define your variable to let compiler know which object file to put it to. Mentioning it in the header file as extern string configpath; just tell compiler that somewhere there will be this variable, leave unresolved reference and let linker resolve it.
Add to your main.cpp:
string configpath;
In your final invocation to gcc, you only link main.o, but not utils.o.
I met a problem when inspecting the local variables of user space application in systemtap.
I write a test.c like this:
#include <stdio.h>
int func(int *p, int val)
{
printf("p=%p val=%d\n", p, val);
return 1;
}
int main()
{
int a = 7;
func(&a, a);
return 0;
}
and compile it with -g
# gcc -g -o test test.c
Systemtap can see the variable of func(): p and val
# stap -L 'process("./test").function("func")'
process("/home/ryan/Public/test").function("func#/home/ryan/Public/test.c:3") $p:int* $val:int
So I use this stp to watch the variables:
# stap -e 'probe process("./test").function("func") {printf("%s(%p, %d)\n", probefunc(), $p, $val)}'
But the local variables are not right in the result when test program executed, it shows:
func(0x0, 0)
I am using fedora19 with:
kernel-3.11.9-200.fc19.x86_64
systemtap-sdt-devel-2.3-1.fc19.x86_64
systemtap-2.3-1.fc19.x86_64
systemtap-client-2.3-1.fc19.x86_64
systemtap-devel-2.3-1.fc19.x86_64
systemtap-runtime-2.3-1.fc19.x86_64
gcc-4.8.2-7.fc19.x86_64
Could someone meet this problem or give me a solution?
.function probes are defined to fire at entry to the function. If you're looking for values of local variables, you need to use .statement probes, identifying the source-file:line-number. In this case though, you're looking for parameters to a function (which happened to be based on another function's locals). In this case, the .function probe is appropriate.
You appear to be hitting a GCC bug. In plain -g mode (ironically), dwarf debuginfo is sometimes inaccurate for incoming function parameters. Try "gcc -g -O" or "gcc -g -O2" instead. Systemtap prologue-searching (stap -P) might help. See also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51358, https://sourceware.org/bugzilla/show_bug.cgi?id=13420
In case the "stap -P" doesn't help, you may need to resort to statement-level probing after all:
probe process("./test").statement("func#test.c:5") { println($$parms) }
(line :5 refers to the printf)
Why am I not able to compile my code to c++ 11 and use the srand48 function?
I have a program where I play around with some matrices.
The problem is that when I compile the code with the -std=c++0x flag.
I want to use some c++11 only functions and this is my approach to do so.
It compiles without any problems if I do not specify the c++ version. Like this:
g++ -O2 -Wall test.cpp -o test -g
Please correct me if I have misunderstood what the mentioned flag does.
I run my code on a Windows 7 64-bit machine and compile through cygwin. I use g++ version 4.5.3 (GCC). Please comment if more information is required.
For some unknown reason (even to myself) then all my code is written in one compilation unit.
If the error is caused by a structural error then you should also feel free to point it out. :)
I receive the following errors:
g++ -std=c++0x -O2 -Wall test.cpp -o test -g
test.cpp: In function ‘void gen_mat(T*, size_t)’:
test.cpp:28:16: error: there are no arguments to ‘srand48’ that depend on a template parameter, so a declaration of ‘srand48’ must be available
test.cpp:28:16: note: (if you use ‘-fpermissive’, G++ will accept your code, but allowing the use of an undeclared name is deprecated)
test.cpp:33:28: error: there are no arguments to ‘drand48’ that depend on a template parameter, so a declaration of ‘drand48’ must be available
Here is a sub of my code, it generates the errors shown above.
#include <iostream>
#include <cstdlib>
#include <cassert>
#include <cstring>
#include <limits.h>
#include <math.h>
#define RANGE(S) (S)
// Precision for checking identity.
#define PRECISION 1e-10
using namespace std;
template <typename T>
void gen_mat(T *a, size_t dim)
{
srand48(dim);
for(size_t i = 0; i < dim; ++i)
{
for(size_t j = 0; j < dim; ++j)
{
T z = (drand48() - 0.5)*RANGE(dim);
a[i*dim+j] = (z < 10*PRECISION && z > -10*PRECISION) ? 0.0 : z;
}
}
}
int main(int argc, char *argv[])
{
}
Regards Kim.
This is the solution that solved the problem for me:
First n.m. explained that srand() can not be used when compiling with -std=c++0x.
The correct flag to use is -std=gnu++11 however it require g++ version 4.7+
Therefore, the solution for me was to compile my code with -std=gnu++0x
The compile command = g++ -O2 -Wall test.cpp -o test -g -std=gnu++0x
If you explicitly set -stc=c++03 you will get the same error. This is because drand48 and friends are not actually a part of any C++ standard. gcc includes these functions as an extension, and disables them if standard behaviour is requested.
The default standard mode of g++ is actually -std=gnu++03. You may want to use -std=gnu++11 instead of -std=c++0x, or pass -U__STRICT_ANSI__ to the compiler.