I am debugging and looking at code generated by the C compiler (for a Silabs 8051F312) and I am seeing it go to the middle of code in breaking from a case statement. Of course its infuriating ... so I suspected that it was the code optimizer but no, it really completely subverted my logic. Where do I do to follow its bad logic and pinpoint the problem. The .lst doesn't help since its shows the code all nested fine. I was thinking the line files are screwed up but recompiling it gets the same results. The assembly code, clearly shows the jump into the middle of code shown in the line files. HELP??? :)Rik
Are you sure there's actually something wrong with the flow of execution? You might want to post both the C source and compiler output. (Note the pre and /pre tags.) A source-level debugger can often be confused by highly optimized code. One line of C may correspond to many lines of assembler. When the optimizer is done, some of those lines of assembler may be shared with many lines of C. But the debugger chooses exactly one source line to show for any given address. Thus, the source window can hop about strangely. Code for entry and exit (whether for procedures, or cases in a switch) often winds up being shared. Does your program flow correctly if you switch to the assembler view and single-step through it?
Have you tried just reducing the optimisation level to the minimum? I find that 'case' statements are often particularly "badly" affected by optimisation (that is "badly" in the sense of "hard for source-level debugging" - it's very good in the sense of run-time efficiency...!)
unforunately not. Sad to say, hard to figure, but the source compiles wrong. You see, I am setting up a particular value to a variable for a state machine and then I have a break to leave the switch/case. The assembly clearly shows it going to a place close to the end of the switch but to an instruction with the same state machine variable (the second line of two clean lines of code). Unfortunately, that state variable setting is the wrong setting. The grey boxes for the debugger and the even the assembly/line listing blatantly show the compilation mistake. I readily imagine that the process of code generation is stable - but this is blatantly bad code generation. I don't know how the assembler listing binds to the C line listing. I am pretty sure i am rebuilding everything everytime so i don't know what file could be stale (needing to be remade). I have regressed back to a version that works which wastes a few days (weekends you know). Thanks for listening ... compiler generation bugs are the most scary of all. :)Rik
thank you much. I am always appreciative of code optimization and figured that is what happened unfortunately in this event, it did not generate properly. The assembler has clear labels (merged with the c code) and it is clearly going there in the listing and the debugger. CPU is behaving as shown. thansk. :)r
Have you reported this to our technical support department? What version of the compiler are you using? Can you show the listing with the bad code? If there is a problem in the compiler we would like to correct it. However, to do that we need your help. Jon