- What is a
breakpoint:
- Breakpoint =
a location in the
program where
execution will be
temporarily halted when the
program execution arrives at
that location
A breakpoint must always be marked by an .global label in the program
- Breakpoint =
a location in the
program where
execution will be
temporarily halted when the
program execution arrives at
that location
- Pre-requisite to
fixing a
computer program:
- Before you can
fix
something (anything) that
is broken, you need to
know the
difference between:
- Something that work correctly
- Something that does not work correctly
In other words:
- If you do not understand how an algorithm works, you will not be able to fix the algorithm !!!
- Before you can
fix
something (anything) that
is broken, you need to
know the
difference between:
- Fact:
- A good programmer knows exactly what steps (and effects) his/her program (algorithm) will perform
- How a
good programmer
finds errors in his/her
programs:
- They make their program
show them
what it is
doing
When the program is doing something unexpected (= something other than what the program should do), a good programmer has find the bug !!!
- They make their program
show them
what it is
doing
- Before you can
use
breakpoints to help you
find bugs in your
program, you
must first:
-
Locate the
general (= approximate) area
in your program that contain
a bug
I.e.: find out when an error occured in the execution of your program !!!
- You must know (understand) what your program is doing (to the variables) in order to discover when an error has occurred !!!
-
Locate the
general (= approximate) area
in your program that contain
a bug
- Medthodology used to
find bugs in a
program:
-
Suppose that the
bug (= error) is
located this
this part of your
program:
- How to
find the bug (= error) in
your program:
- Execute each instruction in the suspect area
- Check if the result of each instruction is exactly what you expect the program to perform
The instruction(s) that fail to perform what you expect them to do, are errors
-
Suppose that the
bug (= error) is
located this
this part of your
program:
- $64,000 question:
- How can I
make the computer to
execute
each instruction in the
suspect area ???
- The program will always start running from the beginning !!!
- How can I
make the computer to
execute
each instruction in the
suspect area ???
- Fact:
- Breakpoints can help you get to (or get "close" to) the part of the program that contains a bug
- How to
use
break points to help you
find bugs:
- Suppose you determined that
this part of your
assembler program contains a
bug (= error):
- Then define a .global label
just before
the suspect section:
This labeled must be defined using .global !
- Save and re-compile
the program and run it in Egtapi
- Add
the breakpoint
debug1
(optionally: save the
debug start up file)
- Run the program until it
reaches the break point
debug1
- Then Step through
each instruction in the
problem section and
observe how the code update
the registers/variables
Recall:
- In order to find a bug in a program,
you must know
what your program
must do to achieve the correct result
- When some instruction
is not doing what
you expect to do, you have found your bug
(But if you have no idea what your program should accomplish, then you need to brush up on your knowledge before you can tackle this task).
- In order to find a bug in a program,
you must know
what your program
must do to achieve the correct result
- Suppose you determined that
this part of your
assembler program contains a
bug (= error):
- Consider the
following
program with a bug in
the body of a
loop:
- If you have a bug
that is inside a loop, finding the
bug is a bit
tricky because:
- The error may
not manifest itself
(= program crash) during the
first few executions of
the loop
Example:
- Suppose
you have an array of
100 elements, and your
loop k accesses
the kth element of
the array as follows:
for ( k = 0; k <= 100; k++ ) { access array element A[k] } - The loop will crash after 100 iterartions !!!
If you step all the instructions in a loop, you will waste a lot of time going through many iterations of the loop to find your bug (error) !!!
- Suppose
you have an array of
100 elements, and your
loop k accesses
the kth element of
the array as follows:
- The error may
not manifest itself
(= program crash) during the
first few executions of
the loop
-
I use the following
2 step debug procedure
to cut the time to
find the bug:
- Find out which iteration
of the loop the
error will
manifest itself
- Skip over the non-crashing iterations and then single-step through the execution of the iteration that causes the program error
How to perform the 2 step debug procedure:
- Find out which iteration
of the loop the
error will
manifest itself
- Put a breakpoint
debug1
before
problem area in the loop:
- Run the program.
(The program will
stop at the
debug1
breakpoint
)
- Then repeatedly click the
"Run" button....
- The program will repeatedly
stop at the
debug1
breakpoint
Keep pressing the Run button until the program crashes
You must count the number of times that you have clicked the "Run" button !!!
- The program will repeatedly
stop at the
debug1
breakpoint
Let n = the number of times that you have clicked the "Run" button
(I.e.: n = the iteration number in which the loop crashes)
- Put a breakpoint
debug1
before
problem area in the loop:
- How to do the
debugging step:
- Reload the
program
- Put a
breakpoint
at debug1 again
if necessary
- Run the
program.
(The program will
stop
at the breakpoint
debug1)
- Then click the
"Run" button
for
n−1 times !!!
- The program will repeatedly
stop
at the breakpoint
debug1
We know that the first n−1 times through the loop was OK --- so don't waste time stepping thorugh each instruction of the loop !!!
- The program will repeatedly
stop
at the breakpoint
debug1
- When the program
stops after
n−1 times
through the loop:
- Use the "Step" button to execute and verify/observe/check the execution of each instruction to find the error !!!
- Reload the
program
- Find out which iteration
of the loop the
error will
manifest itself