Hi, whilst debugging code running on my XC161board i cant seem to modify the locals in the watch window. Does anyone know why this is?
Are you in run mode or stopped when trying to modify the locals?
Is the local allocated to a register?
Are the local in-scope when you try to modify them?
Hi, yes they are in scope, they are displayed in the local window with values when stop executing, but if i change them, they dont accept the change, using F2 in watch window to change. I dont know if they are register? how would you know and why would they be?
Cheers.
Why would they be? Because they are locals, and the compiler want to use registers for locals since most processors and processor instructions works best on registers.
Registers have much better bandwidth than memory cells.
Sorry, im really new to this, so if they are in registers you cant modify them in the watch window? what make them decide to be in registers? I noticed that i could modify some locals but not most at one point, so why when i stop execution in a function was some editable and some not? and can i change this behaviour? Thanks,
"what make them decide to be in registers?"
It's the compiler that decides.
"can i change this behaviour?"
You might be able to change it via the compiler's Optimisation settings - see the Manual for details...
This is a very valid question!
The whole point of an IDE is that it's supposed to be Integrated - that's what the 'I' stands for, isn't it?
[rant] How can this be called "Integrated" if the Keil debugger can't even understand such basic optimisations as this done by the Keil compiler?!
This is not some fancy new and revolutionary optimisation technique; compilers - including Keil compilers - have been doing it for years! Is the state of debugger technology really this far behind?! [/rant]
It depends a bit.
All real debuggers should support edit of variables even if stored in registers.
The problem comes when the variable is only used in some part of a function. The compiler may then reuse the register for a different variable in other parts of the function. The result is that the variable goes out of scope for the debugger, even if you still are within the block scope of the source code.
"result is that the variable goes out of scope for the debugger, even if you still are within the block scope of the source code."
That's true, although a truly integrated debugger worthy of the name should be able to cope with it.
The trouble really is that the debugger technology (certainly within uVision) really is a long way behind the compiler technology - especially when it comes to oprimisation.
:-(
View all questions in Keil forum