I'm working with some code running on an LPC2378-based board. I'm attempting to JTAG debug the target using uLink2. When I'm stepping through code, however, program flow doesn't seem to follow the path I think it should and multiple "next instruction" arrows are often shown (though one is yellow and one is light blue). I've tried looking through the uVision4 documentation, but can't find any reference to a light-blue arrow or any hint at its meaning.
I've used DK-8051 previously for some 8-bit work and never seen this behavior. I'm new to MDK-ARM and have been foiled a bit in trying to figure out what's going on. Any insight would be greatly appreciate.
In my experience that blue arrow is not "next instruction". That arrow indicates the relation between the disassembly window and the C source. I.e. if you click on an active source line (one that code was actually generated for) while the disassembly window is open, the focus will move to the disassembly, and the blue arrow will be on the line you clicked on. Likewise if you click on a line in the disassembly, the blue arrow will move to the source line(s) corresponding to it.
Hans-Bernhard,
Thanks, I'll check that and see if the multiple arrows in fact has nothing to do with the issue. If that's the case, then does anyone have experience on what would cause strange behavior such as the next-instruction arrow not moving according to the program flow expected and/or watch values not updating in the window until MANY statements after the one I expected to update them?
what would cause strange behavior such as the next-instruction arrow not moving according to the program flow expected and/or watch values not updating in the window until MANY statements after the one I expected to update them?
I know you said you had checked against that by going to optimization 0, but: those are definitely tell-tale signs of compiler optimization. Do yourself a favour and closely inspect the machine code --- and at different optimization levels, too.
But keep one thing in mind: there never was any guarantee that a C compiler will emit code that does things in the same sequence your source code does them. Not even at -O0. The compiler is explicitly at liberty to emit whatever code it wants, as long as the net result (in terms of values put into variables, registers etc.) is correct. If you really want that level of control, you really have to code in assembler.
Turns out that all of our first instincts (signs of optimization) were correct. I had set optimization level to -O0 in the "options for Target. . ." settings. HOWEVER, someone had overridden those settings for the entire source group within the project and set it to -O3. Thanks for everyone's help and sorry for the wild goose chase.
As an aside, however, I WOULD still like to know what the blue next-statement arrows mean. Sometimes there were more than one of them and they appeared even when the disassembly window wasn't being displayed. I think they're possibly trying to give some clue about what the optimized code is doing, but I haven't seen an explicit definition of their meaning anywhere in the documentation.
-Jay Daniel
just a possible example
func1 x; blah func2 y; blah func3 z; blah
if the optimizer optimizes as follows
func1 x; jump blah func2 y; jump blah funcz z; jump blah blah ret
the debugger may have some doubts as to where you go on the 'ret'
Erik