We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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.
.
Erik,
I thought that too, but recompiled with optimization level 0 and still saw the exact same behavior. I'm thoroughly stumped. I almost suspect it's a code synchronization issue, but can't figure out how to confirm that or correct it readily.
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
what version of the editor are you using?
just curious what does what version of the editor are you using? have to do with debugging 'markers'
MDK-ARM v 4.50 is using a new engine for the editor - so lots of little things changed. Like setting a breakpoint is a single click to the left of the line numbers, instead of a double click.
So if he is using 4.50, there could be so bugs introduced by introducing a new backend.
A google search of the website sent me to this link:
"The cyan arrow is where the source and disassembly windows are matching. You set this with your mouse"
http://www.keil.com/appnotes/files/apnt208.pdf
Playing around with it the Cyan arrow seems to be a mulit-purpose arrow
If you do a find in files search, and double click on an entry in the "find in files window", the cyan arrow points to the appropriate line.
If you get a double click on a warning in the output window, the cyan arrow points to the appropriate line.
If you have the dissasembly window open as the active window, where ever the yellow bar is in the dissasembly window, there will be a cyan arrow pointing to the appropriate line in the C source.
Single step through the dissasembly code to see if the code has been optimized. C (source code will be in red, assembly code will be in black. At level 0, there should be a 1-1 correspondence.
Please note that at even at level 0 the compiler can perform "some simple source transformations"
http://www.keil.com/support/man/docs/uv4/uv4_dg_adscc.htm