In the Eclipse debugger, is it possible to manually (and conveniently) change the program counter by clicking on a line and request, "change program counter to this line"? I am trying to debug a function by manually recalling it within the debugger, instead of having to restart my program each time.
Thanks.
Change program counter with debugger
Re: Change program counter with debugger
Here is a re-post of the answer given through NetBurner support:
Yes you can jump the PC in the debugger but I highly suggest you do
not do this. There is a high probability of bad side effects when doing
this. You are much better off using a standard break point. Once you are
stopped at a break-point you can also right-click on a line of code and
selecting "run to line", which is pretty much the same thing as a normal
break-point but it only will occur once.
If you just jump to another location in your code there are many things
that can go wrong. Since you are running the RTOS, you MUST make sure
you are in a location of the same task. If you jump to another task
then the stack will likely get corrupted when the task scheduler runs.
Basically it will load that program counter and register values onto the
wrong task stack, then any jump back to the original task will bring you
to the wrong task and a jump to the new task will start you where that
task was originally pending. Also the registers and memory will be
initialized to a different configuration then what they would be if your
application ran to the point you want to jump to. Since it is pretty
difficult to fully grasp how the compiler decided to manage the memory,
it is very likely the registers and memory state will cause problems
either at the jump location or somewhere down the code after your jump.
I only will modify the PC when I am testing assembly language blocks of
code since I am fully controlling the registers and memory. I usually
do not use the debugger to do this, I simply use a goto statement in my
code. You can also use a goto in C++. This is considered a major
"no-no" for c++ since it leads to memory leaks, it's hard to read and
also difficult to maintain. Goto statements are still fine to use for
debugging purposes and are much safer then forcing jumps with the
debugger. To use a goto just make a label anywhere in your application...
MY_GOTO:
Then just call "goto MY_GOTO;". The difference between this and a
normal function call is that there is nothing loaded onto the stack and
there is no return to where the goto was called.
Here is the unrecommended way to jump in the debugger, you must first be
stopped at a valid break-point. You can right click on any line in your
code and select "Resume at line". This will modify the PC to be at the
lines location. You can also manually modify the PC just like any other
CPU register. At a valid break-point look at the register window in the
top right of the debug perspective. Expand the task struct to see all
the registers, one will be called PC. If you right click on this PC
register you can select "change value". Just put in any hex value you
desire.
Yes you can jump the PC in the debugger but I highly suggest you do
not do this. There is a high probability of bad side effects when doing
this. You are much better off using a standard break point. Once you are
stopped at a break-point you can also right-click on a line of code and
selecting "run to line", which is pretty much the same thing as a normal
break-point but it only will occur once.
If you just jump to another location in your code there are many things
that can go wrong. Since you are running the RTOS, you MUST make sure
you are in a location of the same task. If you jump to another task
then the stack will likely get corrupted when the task scheduler runs.
Basically it will load that program counter and register values onto the
wrong task stack, then any jump back to the original task will bring you
to the wrong task and a jump to the new task will start you where that
task was originally pending. Also the registers and memory will be
initialized to a different configuration then what they would be if your
application ran to the point you want to jump to. Since it is pretty
difficult to fully grasp how the compiler decided to manage the memory,
it is very likely the registers and memory state will cause problems
either at the jump location or somewhere down the code after your jump.
I only will modify the PC when I am testing assembly language blocks of
code since I am fully controlling the registers and memory. I usually
do not use the debugger to do this, I simply use a goto statement in my
code. You can also use a goto in C++. This is considered a major
"no-no" for c++ since it leads to memory leaks, it's hard to read and
also difficult to maintain. Goto statements are still fine to use for
debugging purposes and are much safer then forcing jumps with the
debugger. To use a goto just make a label anywhere in your application...
MY_GOTO:
Then just call "goto MY_GOTO;". The difference between this and a
normal function call is that there is nothing loaded onto the stack and
there is no return to where the goto was called.
Here is the unrecommended way to jump in the debugger, you must first be
stopped at a valid break-point. You can right click on any line in your
code and select "Resume at line". This will modify the PC to be at the
lines location. You can also manually modify the PC just like any other
CPU register. At a valid break-point look at the register window in the
top right of the debug perspective. Expand the task struct to see all
the registers, one will be called PC. If you right click on this PC
register you can select "change value". Just put in any hex value you
desire.