Hi all, I have a little question regarding gcc, does the -g option for the mb-gcc/powerpc-gcc compiler makes the executable code (xxxx.elf) bigger ? does it effect the memory size of my program and if so should I strip it for my final version in order to save some BRAM space (after finshing the debug stage) ? Thanks in advance, Mordehay.
Of course enabling debugging information makes the file bigger, which in its turn obviously requies more memory. The gcc has several levels of optimization, which you can try enabling when you are done with your debugging.
/Mikhail
Thanks alot....
Hi, I usually compile without the -g option when I have made all the debug I need. So bigger version to test it, if it works, compile again and go with the smaller. Marco
I tried compiling an example code both with -g and without and then I run the "objdump -S" and I saw that the result looked almost the
same for both resultant .elf files. It was actually the file without the -g option that had some more lines... how can it be so ? I expected
the file with the -g option to be bigger and more specified, can someone please advise? maybe I need to use more switches for the objdump in order to see the debug symbols ? Thanks, Mordehay.
The -g option doesn't change the code. It adds symbol tables so that data addresses and instruction address points to the source and names within the source code.
The .elf files becomes much larger due to this but the objdump -S should stay the same.
This is from the gcc manual
COFF, XCOFF, or DWARF 2). GDB can work with this debugging information.
information that only GDB can use; this extra information makes debugging work better in GDB but will probably make 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).
occasionally produce surprising results: some variables you declared may not exist at all; flow of control may briefly move where you did not expect it; some statements may not be executed because they compute constant results or their values were already at hand; some statements may execute in different places because they were moved out of loops.
reasonable to use the optimizer for programs that might have bugs.
Göran Bilski
Hi G=F6ran, When using the powerpc-eabi-size on the executable.elf - the size remains the same (with and without -g option) so can I assume that the size of my program will occupy in memory (BRAM used space) remains the same with and without the -g option ? and if so I can leave it even after the debug stage is done (final version) dont I ? Thanks, Mordehay.
Hi Mordehay,
Since the debug symbol tables isn't downloaded or initiated in the memory, your BRAM usage will be the same. The symbol table is only needed for the debugger to show the user what addresses correspond to in the source code.
Göran Bilski
Thanks G=F6ran ....=20 Mordehay
I'm not familiar with this particular case, but sometimes the compile-for-debugging option disables some optimizations that rearrange code enough to confuse the debugger.
-- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.
That's only a very minor effect with gcc and gdb, since the tools (and the debugging symbols file format) are capable of debugging pretty heavily optimised code. It is standard practice to mix debugging and optimisation (such as -O1 or -O2) during development and testing - indeed, for many targets, the generated assembly code is clearer with
-O1 than no optimisation. You are right in theory, of course, and there may be some minor changes when -g is enabled, but not much.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.