CHAPTER-5

CHAPTER-5
DEBUGGING
DEBUGGING
Definition of Debugging
Debugging, in computer programming and engineering, is a
multistep process that involves identifying a problem,
isolating the source of the problem, and then either
correcting the problem or determining a way to work around
it. The final step of debugging is to test the correction or
workaround and make sure it works
Insoftware development debugging involves locating and
correctingcode errors in a computer program.
Debugging is part of thesoftware testingprocess and is an
integral part of the entire software development lifecycle. The
debugging process starts as soon as code is written and
continues in successive stages as code is combined with
other units of programming to form a software product. In a
large program that has thousands and thousands of lines of
code, the debugging process can be made easier by using
strategies such asunit tests,code reviewsandpair
programming
 Once an error has been identified, it
is necessary to actually find the error in
the code. At this point, it can be useful
to look at the code's logging and use a
stand-alone debugger tool or the
debugging component of an integrated
development environment IDE
We divided Debugging in to two types
Dynamic Debugging
Static Debugging
 Dynamic Debugging System
Dynamic debugging involves observing
out puts; register contents, and flags
following the execution of either
instruction or a group of instructions
The dynamic debugging system (DDS)
is a powerful debugging facility for
8080 assembly language programs.
DDS operates in a variety of ways
which you
select to meet your needs.
DDS can run your program one instruction at a
time, automatically maintaining on the screen a display
of all registers, the
ensuing instructions, and portions of memory
Like conventional debugging programs, DDS can also
operate in a breakpoint mode in which the program runs
at full speed until it reaches one of several selected
instructions
The automatic program monitoring facilities provide a
powerful alternative to breakpoints
DDS can run the program for you, until a condition
specified occurs or DDS detects an error by itself.
DDS functions fall into three general categories:
1.Program Display
2. Program Execution Control
3. Program Monitoring Functions
 1 Program Display
DDS displays the basic data used by your program.
This display is automatically updated by DDS. It does
not have to be continuously requested
The DDS display includes the following:
The next five instructions to be executed in mnemonic
format together with hex addresses and op codes.
All operating registers and the words pointed to by
the BC, DE and HL registers pairs.
The stack pointer and the last five words pushed onto
the stack together with the words they point to.
A mnemonic expansion of the condition codes.
The return addresses from the last five CALL
instructions

 2 Program Execution Control

DDS provides a wide range of commands
that allow you to communicate with your
program, change registers, memory,
instructions, data, etc. Among the
facilities provided are:
Register and register-pair modification
data modification, by byte or word, in hex
or characters
stack modification, commands to PUSH
and POP data to the stack
memory moves, memory filling, memory
searching
 3 Program Monitoring
You specify the number of program instructions to be executed
before control is returned from DDS. After executing each instruction,
DDS tests various stop conditions and pauses with a message if any
are met. You select some of the conditions while DDS automatically
checks for others.
Following are some of the stop conditions DDS can monitor for you:
Address Stop - DDS stops when a specified address is reached. This
is similar to a breakpoint, except all other stop conditions are
tested.
Op code Stop - DDS stops when a specified op code is executed.
This facility makes it easier to use DDS when you don't have the
most recent program listing.
Value Stop - DDS stops when a register, register-pair, byte or word
attains a specified value. This is especially valuable when you want
to see what happens at a Particular iteration of a long loop and
don't want to breakpoint through each iteration.
Store Stop - DDS stops when the program attempts to store into a
specific location. This is useful when you know the program is storing
data incorrectly, but you don't know which instruction is responsible.
Address Ranges - DDS stops when the program references data on
side a set of predefined ranges.
 DDS DISPLAY
The DDS display is divided into four distinct regions:
Program Status
Memory Display
Error Message Line
Command Input Line
Program Status Display
The program status display indicates the current
contents of the
programs operating registers and important memory
locations. It is divided into the following sections:
Stack
Instructions
Registers
 Stack
The stack display shows the value of the stack pointer the top
most entry is the last item pushed onto the stack. The format
of an entry on the stack is:
nnnn = xxyyzz
where:
nnnn is the actual address on the stack
xxyy is the word located at address nnnn. This word is
displayed reversed to conform to standard 8080 conventions,
i.e.,
yy is the byte at address nnnn, xx is the byte at address
nnnn+1
Zz is the character representation of xxyy. Non-displayable
characters are represented with periods
Instructions
The instructions to be executed are displayed in program
mnemonics. The address of the instruction is displayed to the
left of the mnemonics, the hex op code is displayed to the
right.

 Registers
the register display shows the contents of the operating registers, as
well as the words pointed to by the BC, DE and HL register pairs. The PSW is
displayed on the first line in the following format:
AF=xxyy
where:
xx is the value of the A register
yy is the value of the condition flag portion of the PSW. A mnemonic
interpretation of the condition flags is also provided and is described in
Memory Displays
DDS can display memory in either a combined hexadecimal or ASCII format or
as program mnemonic codes.
The memory display follows the program status display and is either 6 lines
long for 16 row displays, or 11 lines for 24 row displays.
Error Message Line
after executing each instruction in the program, and after each type in, DDS
checks a series of conditions which the programmer has specified, and certain
conditions of its own. When this process detects errors, they are displayed on
the error line. Each error has a two character code, which
corresponds to the first two characters of the command type in which is being
detected, or a two character code assigned by DDS for conditions it checks
itself. The error line is the second to last line of the display.
 Command Input Line
The command input line is the last
line of the DDS display. It begins with
the prompting characters =>. Input
entered from the keyboard is
displayed here. The command line is
displayed until it has been
successfully executed at which time
it is cleared.
 Static Debugging
Static debugging is similar to visual inspection of a circuit board; it is
the paper-and-pencil check of a flowchart and machine code.
Translating the assembly language into the machine code is similar to
building a circuit from a schematic in that the machine code will have
errors just as would the circuit board. If an assembler is used to
translate the code, most of the errors involved in hand assembly can
be eliminated. The following errors are common in manual assembly:
Selecting a wrong code.
1. Forgetting the second byte or third byte of an instruction.
2. Specifying the wrong jump location.
3. Not reversing the order of high and low bytes in a Jump
instruction.
4. Writing memory addresses in decimal, thus specifying wrong
jump locations.
The debugging problems given in the Assignments section at the
end of the chapter will illustrate some of these errors
 Debugging Programs
A debugger is a program that allows you to step through another program one
line at a time. This is very useful when trying to identify incorrect code
and analyze how a program "flows". Key concepts include: Breakpoints,
Stepping, and Viewing data.

The Debugger
The debugger is a program that can runyour programone line at a
time. Thus the debugger can show you exactly how the
computerseesyour code.
You could think of the debugger as "instant replay" (or film review) in
sports, allowing you to see "step by step" what happened in a given play.
Coaches use this all the time to find the strengths and weaknesses of
their team. The debugger does the same thing. It shows you what is
happening in your program at any moment in time, and allows you to
"step by step" through the program.
Proper use of the debugger is essential to finding semantic (logical)
errors in how your program behaves. The debugger should be considered
your best friend while programming (that is, unless you can perfectly
visualize how your program will run in your head).
Like any tool, using the debugger will take practice, but it is well worth
the investment. Using the debugger to find errors can greatly reduce the
time it takes to perfect a program.
 What the debugger does for you
The "power" of the debugger is that it lets you see the
"state" of your program at any point and to advance
through your program ("step") one line at a time inthe
exact same mannerthat the code is being executed by the
computer.
Key things that you can use the debugger to determine are:
1. The flow of the program
2. The creation of variables
3. The data being stored in each variable
4. The entering/leaving of functions
5. The calculations that are made
6. The entering of IF statements or ELSE statements
7. The LOOPING of code.
 In order to use the debugger you need to know about the following concepts:

Current Line
A computer can only do "one thing at a time". Thus the computer, when running your
program, always has the notion of the "current line". Usually, control of the program flows from
the current line to the next line down the screen, to the next line
In Mat lab, a Green Arrow (in left column) will point to the current line that is about to be
executed. .
In GDB(using the GDB debugger in Emacs to debug C programs), a little white arrow will
be shown on the left hand side of the window, pointing at the current line
Breakpoints
Normally when you run a program, even in the debugger, it will start at the beginning of the
program and run until completion or an error occurs
Often you may know that the error occurs in a certain function (or part of your program), but
that function is not utilized by your code until long after the start of the program. Breakpoints
tell the debugger where to "halt" the execution of your program so that you can see what is
going on
In Mat lab: To "set" a breakpoint, click in the left column on one of the dashes next to the
line of code you are interested in. A red dot should appear.
In Mat labto "remove" a breakpoint, click on the "red dot" that represents the breakpoint
(in the left column).
In GDB: To "set" a breakpoint, put the cursor on the line you want and press Cntl-Spacebar.
In GDBto "remove" a breakpoint, type "del #", where # is the number of the breakpoint.
Type "break" to list all the breakpoints.

 Stepping
Stepping is the action of "telling the
debugger" to advance through your
program one line at a time. Remember, a
computer program is many small steps
combined to form a large goal. It is often
the case that one of these small steps is
"incorrect". To identify which step is
incorrect, we"step"through the program,
looking at each line of code as we come to
it, and seeing what effect this has on
thevariables(really the data in the
variables).
There are several ways you can tell the debugger
to move through the code:
Step In
Complete the next line of code. If this line
contains a function, go to the first line of the
function's code and stop, waiting for the user to
now debug the function.
In Matlab: Step In is represented by the arrow
between two pages
In GDB: To step to the next line, or into a
function, use: "step" (or "s"))
Again, remember, if your arrow is at a function
call, you will "enter" the code for the function and
stop at the first line of the function.
 Step Over
Stepping over means to move to the
next line of code in the current function.
Even if the current line is a function
call,all the codefor that function will be
executed (with out you seeing anything
but the result), and the new current
next line will be the next line of the
code that you were looking at.
In Matlab:Step Over: use the button
with an arrow by a single page.
In GDB: type "next" or "n"
 Step Out
If the current line of execution in the
program is inside the code of a function
and you want to "Finish It" (complete all
the rest of the code in the function), you
can use the step out command. This will
complete all the code in the current
function and return you to the previous
function that "called" this function.
In Matlab:Step Out is the button with
the arrow going up.
In GDB:type "finish".
 Continuing Execution of the
Program
The continue action tells the computer to
"resume" the program (moving forward through
the program's code until another breakpoint is
encountered or until the program ends).
In Matlab:the continue command is the button
with the straight down arrow.
In GDB:you will need to type "continue" or "c"
for short.
Exiting the Debugger
Once you have used the debugger to find an
error in your code you will want to:
Fix the problem (re-write your code)
Stop the current debugger session
Perhaps put a breakpoint on the line you just
 The Debugging Session
Using a debugger is usually a repetitive
process. You write some code, run it, it
doesn't work, so you debug it, fix
something, run the debugger again, fix
something, run the debugger again, etc.
You will often use the following sequence of
commands:
1. Set a breakpoint
2. Run the program via the debugger
3. Look at the results of the variables
associated with the current function.
4. If everything looks good: