GCC debug option documentation is not that comprehensive. So trying to compile a binary with different options -g, -g1, -g2, -g3 I got the following result.
When compiling with -g and -g2 binary has the same 13KB in size.
When compiling with -g1 the binary ended up in 9.3KB in size
When compiling with -g3 the binary has 73KB in size
So is -g equivalent to -g2? But the level 2 is not even explained in the documentation. Here is what the docs say (no level 2):
Level 0 produces no debug information at all. Thus, -g0 negates -g.
Level 1 produces minimal information, enough for making backtraces in
parts of the program that you don’t plan to debug. This includes
descriptions of functions and external variables, and line number
tables, but no information about local variables.
Level 3 includes extra information, such as all the macro definitions
present in the program. Some debuggers support macro expansion when
you use -g3.
Or am I missing something?
So is -g equivalent to -g2?
Yes.
But the level 2 is not even explained in the documentation. [...] Or am I missing something?
You are missing something. You have overlooked the sentence immediately preceding your quotation:
The default level is 2.
This means that -g2 means the same thing as -g. (And -ggdb2 means the same thing as -ggdb, etc.) This serves in part as a reference for each of the -g*2 options to the docs of the corresponding unnumbered -g* options, where you will find the relevant documentation. In particular, the documentation for -g2 is the documentation for -g, which appears first in the section.
Related
I am working on a task for the university, there is a webiste that checks my memory usage and it compiles the .c files with:
/usr/bin/gcc -DEVAL -std=c11 -O2 -pipe -static -s -o program programname.c -lm
and it says my program exceeds the memory limits of 4 Mib which is a lot i think. I was told this command makes it use more memory that the standard compilation I use on my pc, like this:
gcc myprog.c -o myprog
I launched the executable created by this one compilation with:
/usr/bin/time -v ./myprog
and under "maximum resident set size" it says 1708 kilobytes, which should be 1,6 Mibs. So how can it be that for the university checker my program goes over 4 Mibs? I have eliminated all the possible mallocs i have, I just left the essential ones but it still says it goes over the limit, what else should I improve? I'm almost thinking the wesite has an error or something...
From GNU GCC Manual, Page 197:
-static On systems that support dynamic linking, this overrides ‘-pie’ and prevents linking with the shared libraries. On other systems, this
option has no effect.
If you don't know about the pie flag quoted here, have a look at this section:
-pie Produce a dynamically linked position independent executable on targets that support it. For predictable results, you must also
specify the same set of options used for compilation (‘-fpie’,
‘-fPIE’, or model suboptions) when you specify this linker option.
To answer your question: yes is it possible this overhead generated by the static flag, because in that case, the compiler can not do the basic optimization by merging stdlib's code with the one you've produced.
As it was suggested in the comments you shall compile your code with the same flag of the website to have an idea of the real overhead of your program (be sure that your gcc version is the same of the website) and also you shall do some common manual optimization such constant folding, function inlining etc. A good reference to these optimizations could be this one
I know that if you execute GCC as such:
gcc -O3 -O2 foo.c
GCC will use the last optimization flag passed (in this case O2). However, is this true for all flags? For example, if I execute GCC like so:
gcc -mno-sse -msse bar.c
Will it support SSE since that was the last flag passed, or would this result in undefined behavior? My initial experimentation seems to indicate that it will support SSE, but I'm not sure if this is true for all cases.
Normally later options on the line override ones passed previously, as you mention in your first example. I haven't personally come across any different behaviour for -m or -f flags, but I don't know of a specific reference in the documentation.
Note that some options don't behave this way:
$ gcc example.c -DABC -DABC=12
<command-line>: warning: "ABC" redefined
<command-line>: warning: this is the location of the previous definition
So there would need to be a -UABC in between there to shut that warning up.
As an aside, clang is particularly good at solving this problem - it will produce a warning if it ignores a command line option, which can help you out.
I am failed to compile builtin example hwserver.c using ZeroMQ APIs. I have tried every possible way.
gcc -lzmq hwserver.c -o hwserver
It prompts me with:
hwclient.c:(.text+0x22): undefined reference to `zmq_ctx_new'
hwclient.c:(.text+0x3a): undefined reference to `zmq_socket'
hwclient.c:(.text+0x52): undefined reference to `zmq_connect'
hwclient.c:(.text+0x94): undefined reference to `zmq_send'
hwclient.c:(.text+0xb8): undefined reference to `zmq_recv'
hwclient.c:(.text+0xe4): undefined reference to `zmq_close'
hwclient.c:(.text+0xf0): undefined reference to `zmq_ctx_destroy'
collect2: error: ld returned 1 exit status
I'm using zeromq-3.2.2 on ubuntu-12.10
Any help really appreciated.
Thanks,
-Sam
Order of arguments to gcc does matter a lot.
Try
gcc -Wall -g hwserver.c -lzmq -o hwserver
You need first the warning and optimizations or debugging flags (e.g. -Wall for all warnings, -g for debugging information), then the optional preprocessor flags (like -D or -I but you have none of them), then the source files, and at last the libraries -lzmq (order is relevant: from high level libraries to low level ones) and the output option -o hwserver (which could be elsewhere).
Read the gcc documentation, notably the chapter about invoking GCC.
Don't forget the -Wall : you really want to get all warnings, and you should improve your code till no warnings are given. You could even want -Wextra to get more extra warnings.
Don't forget the debugging information flag -g: you will need to use the gdb debugger to debug your program.
Later, use -O or -O2 to optimize the binary program (the compiler will then produce more efficient, but less debuggable, machine code). Care about that only when your program is debugged.
As soon as you want to develop real-sized C programs (i.e. your project made of several source files and some header file[s]), you'll need a builder infrastructure, like GNU make (a very common builder; you could try omake instead).
See also this answer to a related question.
try again
gcc hwserver.c -o hwserver -lzmq
Your order of the parameters is incorrect.
When compiling C source code with either gcc or Clang, I always use the -g flag to generate debugging information for gdb.
gcc -g -o helloworld helloworld.c
I noticed that some people recommend -g3 instead. What is the difference between the -g and -g3 flags? Also is there a difference between -g and -ggdb?
From the docs:
-g
Produce debugging information in the operating system's native format (stabs, COFF, XCOFF, or DWARF 2). GDB can work with this
debugging information. On most systems that use stabs format, -g
enables use of extra debugging information that only GDB can use; this
extra information makes debugging work better in GDB but probably
makes other debuggers crash or refuse to read the program. If you want
to control for certain whether to generate the extra information, use
-gstabs+, -gstabs, -gxcoff+, -gxcoff, or -gvms (see below).
...
-ggdb
Produce debugging information for use by GDB. This means to use the most expressive format available (DWARF 2, stabs, or the native
format if neither of those are supported), including GDB extensions if
at all possible.
-gvmslevel
Request debugging information and also use level to specify how much information. The default level is 2. Level 0 produces no
debug information at all. Thus, -g0 negates -g.
....
Level 3 includes extra information, such as all the macro definitions
present in the program. Some debuggers support macro expansion when
you use -g3.
tl;dr: To answer your specific question, -g3 "includes extra information such as macro definitions... Some debuggers support macro expansion when you use -g3", while -g does not include this extra information.
The broader answer is that gcc supports four levels of debug information, from -g0 (debug information disabled) through -g3 (maximum debug information).
Specifying -g is equivalent to -g2. Curiously, the gcc docs say little about what information -g/-g2 includes or excludes:
Request debugging information and also use level to specify how much information. The default level is 2.
Level 0 produces no debug information at all. Thus, -g0 negates -g.
Level 1 produces minimal information, enough for making backtraces in parts of the program that you don't plan to debug. This includes descriptions of functions and external variables, and line number tables, but no information about local variables.
Level 3 includes extra information, such as all the macro definitions present in the program. Some debuggers support macro expansion when you use -g3.
We're facing an interesting topic. Lets say we have a special-functions.c file, basically a library.
We need to optimize the code as getting rid of all unused/unreferenced functions during the build process on-the-fly.
I'm not searching for generally unused (dead) code: some parts will be "dead" in case of compiling to one of the architectures, but it's going to be used in an other architecture build.
Does anybody knows of flags, tools, methods, tricks to do this?
The compiler is standard gcc with ansi 99 C code.
EDIT
I know, this is mainly the part of the linker, but using gcc, the process is not really split into two parts.
From http://embeddedfreak.wordpress.com/2009/02/10/removing-unused-functionsdead-codes-with-gccgnu-ld/ :
Compile with -fdata-sections to keep the data in separate data
sections and -ffunction-sections to keep functions in separate
sections, so they (data and functions) can be discarded if unused.
Link with --gc-sections to remove unused sections.
For example:
gcc -Os -fdata-sections -ffunction-sections test.c -o test -Wl,--gc-sections
I think that a recent GCC (i.e. 4.6) should do that if you compile and link with the -flto flag (link time optimization). I would imagine that having hidden or internal visibility should be relevant (at least for non-static functions).
To my knowledge, the GNU binary utils (ld, in this case) already remove unusesd references on static link