I am using GCC crosscompiler to compile to an ARM platform. I have a problem where, using opitmization -O3 gives me a "bad immediate value for offset (4104)" on a temp file ccm4baaa.s. Can't find this file either.
How do I debug this, or find the source of the error? I know that it's located somewhere in hyper.c, but it's impossible to find it because there is no errors showing in hyper.c. Only the cryptic error message above.
Best Regards
Mr Gigu
There have been similar known bugs in previous releases of GCC. It might just be a matter of updating your version of the GCC toolchain. Which one are you using currently?
In order to debug the problem and find the offending source, in these cases it helps to add the gcc option -save-temps to the compilation. The effect is that the compiler keeps the intermediate assembly files (and the pre-processor output) for you to examine.
Related
I'm trying to diagnose why a seemingly small C function I wrote has produced a large .text section. I have used arm-elf-size and arm-elf-objdump to isolate the object file and function, but I have only been able to get these tools to produce assembly code, which I don't have the time to reverse engineer.
I tried using gcc switches "-g" which is supposed to be compatible with arm-elf-objdump -g, but it keeps producing the error "No debugging information found," which I've googled around for a bit with no clear cut answer (though other people had an identical problem).
Is there any other means of producing mixed C/assembly files so I can isolate the trouble spot in the function? Thanks!
Is there any other means of producing mixed C/assembly files so I can
isolate the trouble spot in the function?
gcc/gas can generate an assembler listing with C source; I recommend these compiler options:
-g -Wa,-adhln=filename.lst
While debugging uboot the step sequence are not continuous.
when i do next(n) at gdb prompt it goes to some other unexpected line.
I am doing a NFS mount on the target and debugging.
Please clarify.
This happens because normally the U-Boot binary produced by GCC has been optimized for size(to consume less storage space). You can build the U-Boot binary without optimization for easier debugging. Take a look at the Makefile of U-Boot and remove any optimization flags.
Information on optimization flags can be found here.
Step debugging also does not work pretty well with the macros and inline functions as the code is not actually placed where these are defined.
#microMolvi's answer is right, you can vim Makefile on top directory of the uboot source, and find CFLAGS replace -O2 (it's O not 0) by -O0, then it's ok to step by step.
By the way, maybe using s(step) in GDB is better.
In reference to my earlier question here, I found out a possilbe bug in GCC 4.4.3 when it did not support following pragmas in the source code for optimization (although it says 4.4.x onwards it does!)
#pragma GCC optimize ("O3")
__attribute__((optimize("O3")))
Tried both above options but both gave compile time errors in the compiler itself(See the error message snapshot posted in the link mentioned above)
Now are there any further options for me to enable different optimization levels for different functions in my C code?
From the online docs:
Numbers are assumed to be an optimization level. Strings that begin with O are assumed to be an optimization option, while other options are assumed to be used with a -f prefix.
So, if you want the equivalent of the command line -O3 you should probably use the just the number 3 instead of "O3".
I agree that this is a bug and should not generate an ICE, consider reporting it along with a small test case to the GCC guys.
Now are there any further options for me to enable different optimization levels for different functions
in my C code?
Your remaining option is to place the functions in their own .c file and compile that .c file with the optimization flag you want.
I am working on 32-bit Fedora 14 system. I'm compiling my source code using gcc.
Does anybody know how to disable warnings while compiling c code?
EDIT: Yes i know. Best thing is to fix those Warnings to avoid any undefined/unknown behavior. But currently here, i have written huge code first time and there are lots of error & warning in first compilation. Here i just want to concentrate on errors first and then i will see warnings.
try to add -w option when compiling
http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
Every body tells use -Wall switch with gcc, but you want to disable it. It is not advised, Use debugger to find it.
Linus Torvalds:
"But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
The best is to find the problem. It will prevent you in future looking for errors, which would not have occured, if you fixed the actual one.
But, if you're sure there is no bug or you have assured the problem is caught by your code, place this somewhere in the file (where 177 the number of your warning is):
#pragma diag_suppress 177 // supress #177-D function was declared but never referenced
let say you are getting warning -Wfoo-bar try to add compilation flag -Wno-foo-bar
Just curious. Using gcc/gdb under Ubuntu 9.10.
Reading a C book that also often gives the disassembly of the object file. When reading in January, my disassembly looks a lot like the book's; now, it's quite different - possibly more optimized (I notice some re-arrangements in the assembly code now that, at least in the files I checked, look optimized). I have used optimization options -O1 - -O3 for gcc between the first and second read, but not before the first.
(1) Is the use of optimization options persistent, aka, if you use them once, you'll use them until switching them off? That would be weird (browsed man file and at least did not see anything to that sort). In the unlikely case that it is true, how do you switch them off?
(2) Has gcc's assembly changed through any recent upgrade?
(3) Does gcc sometimes produce (significantly) different assembly code although same compile options are chosen?
Thanks much.
1) No, the options don't persist.
2) Yes, the optimisers are constantly being changed and improved. If your gcc packages have been upgraded, then it is quite likely that the assembly generated for a particular source file will change.
3) Compiling with gcc is a deterministic process; if you compile the same source with the same version of gcc and the same options for the same target, then the assembly produced should be the same (modulo some symbol names).