i want ask you for some question what can be incorrect,
i write a program in C and translate it in
gcc -Wall -pedantic
and run
valgrind --simulate-cache=yes --tool=callgrind ./a.out
that create callgrind.out.[pid-number]
and if i run
callgrind_annotate callgrind.out.[pid] main.c
out will be
-- User-annotated source: main.c
No information has been collected for main.c
is it any way how to annotate code and calls of function for program optimalize tools ?
note
gcc -g - pg progrma.c
not working because Apple unsuported debug option on gcc and gprof is unsupported too. And KDE program don`t want run on Mac ...
Thanks everyone to helpful information how to solve it
You're compiling with gprof profiling information when you compile with -pg. valgrind doesn't actually need that data to do it's profiling, what it does need is the debug information.
Using valgrind-HEAD, I took a simple piece of code and compiled it without -g and got the same result as you - i.e. No information has been collected for main.c.
When I compiled with -g, I got useful information about main.c, even when I compiled with optimization I got useful information.
Long and short of it is that you need to compile with -g, not with -pg to get it to work with callgrind.
Related
I wanted to compile the below code in VS Code, but I'm fetching this error using "code runner". I've looked up everywhere, but it didn't solve my issue.
I want to implement this T(n) = 2T(n/2) + nlog(n)
q2.c
// b. T(n) = 2T(n/2) + nlog(n)
#include <stdio.h>
#include <math.h>
int func(double n)
{
return (2*func(n/2) + n*(log(n)));
}
int main()
{
double n, result;
printf("Enter the value of 'n' \n");
scanf("%lf",&n);
printf("Hey");
result = func(n);
printf("%lf \n",result);
printf("Hey");
return 0;
}
Console:
user#user-H310M-DS2:~/Desktop/C programming/Assignments$ cd "/home/user/Desktop/C programming/Assignments/" && gcc q2.c -o q2 && "/home/user/Desktop/C programming/Assignments/"q2
/tmp/ccnNXN3L.o: In function `func':
q2.c:(.text+0x3a): undefined reference to `log'
collect2: error: ld returned 1 exit status
Visual studio code has nothing to do with your issue, you are not compiling with it. Because it is an IDE (or source code editor), not a compiler. I guess you are using it on some Linux or POSIX system. BTW my preferred source code editor is GNU emacs. So your IDE is running some compilation commands (and you need to understand which ones and what these commands are doing). You could run these commands in a terminal (and that actually might be simpler).
As your console logs shows, you are compiling with GCC. Some gcc command has been started (by Visual studio code probably).
Read carefully about Invoking GCC. Order of arguments matters a lot!
You should compile your code with
gcc -Wall -Wextra -g q2.c -lm -o q2
Let me explain this a bit:
gcc is your compiler front-end (the actual compiler is cc1 but you never use it directly; you ask gcc to run it)
-Wall asks for almost all warnings
-Wextra asks for extra warnings. You'll be happy to get them
-g asks for debugging information in DWARF. You really want to be able to use the gdb debugger, and gdb practically needs debugging information.
q2.c is the source file of your sole translation unit
-lm is for your math library. You are using log(3) and its documentation mention that.
-o q2 tells gcc to put the executable in q2 (the actual work is done by the ld linker invoked by gcc)
How to configure visual studio code to use that command is your business. You could otherwise type the above command in a terminal. Then you can run your q2 program by typing ./q2 in a terminal for your shell (and you could use gdb on it).
Notice that gcc is starting other programs (like cc1, as, ld). If you want to understand which ones, insert -v after gcc in the command above.
Be sure to read the documentation of every function you are using (so read printf(3), scanf(3), log(3) at least...) and of every program you are using (e.g. of gcc and of Visual studio code).
Once you'll write bigger programs made of several translation units (e.g. foo.c, bar.c, gee.c), you would want to use some build automation tool (because compiling all of them every time with gcc -Wall -Wextra -g foo.c bar.c gee.c -lm -o qqq is possible, but inconvenient). You could learn to use GNU make (or ninja).
Read How to debug small programs. Don't expect your program to work as you want at first.
BTW, study the source code of some existing free software programs (but start with simple projects, e.g. on github, of less than a hundred thousand lines). This could teach you many useful things.
I'm not sure how VSCode compiles programs, but since it uses GCC, it's likely that you need to link the math library libm when compiling, by supplying an argument -lm to GCC.
Just a tweak to code runner's settings.json under file->preferences->settings of VS Code :
I've added the below line
"code-runner.executorMap":
{
"c": "cd $dir && gcc -Wall -Wextra -g $fileName -lm -o $fileNameWithoutExt && $dir$fileNameWithoutExt",
}
It's working now.
On this beginner tutorial at TutorialsPoint, it says to save the code as test.c and compile it using "$gcc test.c -o demo" command at CMD.
But I don't have $gcc. What is it?
Let's split this into parts:
$ is a character indicating that the shell is ready to receive a command. It is not part of the command.
gcc is an executable executing the GNU C compiler from the GCC toolchain.
test.c -o demo are arguments supplied to gcc.
The GCC toolchain is only available natively for GNU systems such as Linux. Using MinGW or CygWin you can ape its functionality, though.
Notes:
A nice comment, which I second, to your question by #iharob:
Don't use gcc test.c -o demo specially if you are a beginner, use gcc -Wall -Wextra -Werror test.c -o demo.
The additional switches make the compiler point out more warnings.
GCC (GNU Compiler Collection. Upper case.) is a set of compilers, that can compile several languages.
gcc (lower case) is a command that compile the code you wrote, using the C compiler that GCC includes, into a working C program. Similar commands are g++ for C++ code, gcj for Java code, etc.
Note GCC is intended for Linux or other Unix-like systems (You can use it in Mac OS X with the help of xcode). If you are using Windows, consider [MinGW] (http://www.mingw.org/) or CygWin https://www.cygwin.com/.
As a beginner, if you still have trouble, consider use Dev-C++, an IDE (integrated development environment) that compiles C and C++. It does all the compiler things for you.
My C compiler was working a second ago and making executables, but I started working on a new .c file and suddenly it won't work anymore. I haven't changed anything and I'm still using the same commands, Gitbash version, etc. The compiler is still able to catch errors, so gcc works, but after calling:
gcc -std=c99 my_file.c
there is no executable called my_file.exe. Help sites online suggest installing additional software to fix the error, but I'm hesitant to do so because everything was working fine earlier and I don't want to aggravate the problem with additional software.
Since you have not specified the name of the file to output, GCC will output a.exe.
If you desire output named something else, you must use the -o flag, for example:
gcc -std=c99 -o my_file.exe my_file.c
On Unix, that compiler command would generate an executable a.out. You may find that there is an executable with a default name — but I don't have Windows to check what that name is. Guesses might include a.exe, a_out.exe, aout.exe, etc.
To get my_file.exe:
gcc -std=c99 -o my_file.exe my_file.c
If you don't specify an output -o flag you will get a.exe by default (a.out on other platforms),
gcc -std=c99 my_file.c
If it is working, produces
a.exe
I think you wanted
gcc -std=c99 -o my_file.exe my_file.c
I'm running into a little problem and require some assistance. I would like to run gprof on some OpenMP and MPI hybrid code as a part of my testing. I understand that Gprof relies on a binary file which is created when you compile GCC (or mpicc) with a -pg switch.
I have tried adding this switch and my compiling succeeds (as in no errors are reported), however, the binary file is not created, but the executable is created as normal. I have also tried doing this on much simpler code, which uses pthreads, with the same result.
Please examine the below and let me hear your thoughts.
gcc -pg --std=gnu99 -pthread -Wall -o pthreadsv0 pthreads.c
GCC compiling with -pg doesn't produce binary needed for Gprof.
I suspect that the binary file you mention is in fact the profile data file (gmon.out), and it is generated when you run your program (which has to be compiled with the -pg flag).
Just execute your program and see if a gmon.out file is there.
The Gprof information is created when you execute the program after you compile with the -pg option. Try running your program. (You're profiling (Gprof) the execution of the program.)
The -pg compile option adds the necessary logic to create the profiling information when the program is executed. Executing the program, several times if desired or needed, allows the 'instrumented' code to write the data describing the logic flow and timing to the gmon.out file.
I encountered the same problem. The problem arose because I was shutting the program's execution with Ctrl + C instead of a proper exit (closing the GUI window in my case).
I want to compile an application with debug information using gcc and gdb. When I do the following, the debug (.dSYM) files are generated correctly:
gcc -ggdb src/test.c -o build/test
If I, however, split this into a compile step and a link step, like this:
gcc -ggdb -c src/test.c -o build/test.o
gcc -ggdb build/test.o -o dist/bin/test
… no .dSYM files are generated at all, and therefore gdb does not show me the source line of code where a crash occurs, which makes debugging a lot more difficult. Since I have quite a bit of source files, compiling and linking them all in a single gcc invocation is not possible.
How can I let gcc generate the .dSYM files when using separate compile and link steps?
Check the second comment on the first answer in this post.
Its a quirk. Maybe you can run the "dsymutil" program manually to generate dSYM files.
You can also specify -g3 in you compilation options so that gcc puts debug symbols right into the binary, not in a separate file. Not sure if that is what you need.