|
Bradd Kadlecik, IBM TPF Development
Along with the Visiting with VisualAge column, we would like to
include some of the questions that we have received from TPF
customers as well as developers in the TPF lab. Call or send us a
note if there are any additional questions you would like to see in
this column.
How do I start using the debugger?
The TPF debuggers for VisualAge clients use two daemons or
servers. One is the registration daemon, which runs on the TPF
system and is started by using the ZDBUG functional message with
the START parameter specified. The other is the debug daemon, which
runs on the workstation and is started either manually by the user
(before APAR PJ25982) or automatically after debug registration.
The registration daemon handles the adding, modifying, and deleting
of registration entries. The debug daemon handles the requests from
TPF to start a debug session. The registration entries are used to
inform TPF where to start debugging. The terminal address is a way
of specifying who or what is going to start the program you want to
debug. The program mask is the program or programs in which to
start debugging. For the C debugger, the only valid programs in
which to start are dynamic load modules (DLMs) that have entry
points compiled with symbol information and test hooks at
optimization level 0. For the assembler debugger, any E-type basic
assembler language (BAL), target TPF, or DLM will do. Once the
debug session is started, flow can continue into dynamic link
libraries (DLLs) and libraries as well.
What are test hooks and why do I need them?
If a program had no test hooks, the ctest() function would have
to be coded at every location in the program where a developer
would want to use the debugger. ctest() is a function call to the
debugger and provides for a stopping point in the application from
which the debugger can gain control. Test hooks are like having
ctest() coded before every C statement, but with an option to NO-OP
the call. Hooks allow the program to call the debugger before each
C statement and at the start or end of each function or block. In
some ways hooks are also like user exits; they do nothing until
they are enabled by either the TPF C Debugger for VisualAge
Clients, performance analyzer, or C function trace. There are
various types of hooks as well. Not only is there a hook
corresponding to each statement (otherwise known as a statement
hook), but entry and exit hooks for each program, function, or
block; before and after hooks for each function call; and hooks for
each conditional or case. Line breakpoints are not allowed on every
type of hook. This is why it is possible to stop at a certain
location and not be able to set a line breakpoint. At optimization
level 1 and 2, only a few types of hooks are allowed, so any
possible use of the TPF C Debugger for VisualAge Clients would be
severely restricted.
How do I get the debuggers to display my source code?
The TPF C Debugger for VisualAge Clients accesses the source
from the workstation. If the DEBUG_PATH environment variable is not
set to tell the debugger what drives and directories to use to
obtain the source, you will then need to provide that information.
To avoid confusion, it is important that the source accessed by the
workstation matches what was used to build the program. When a
program is built through VisualAge for TPF, the source is on an
NFS-mounted drive. Therefore, it is often a good idea to set the
DEBUG_PATH variable to this location. Unlike the C debugger, the
assembler debugger accesses a listing type of file from the TPF
system. This listing view is actually taken from a modified ADATA
file. With corrective service diskette (CSD) 15, an action has been
added to the VisualAge for TPF interface to create such a file and
put it on the TPF system. After the ADATA file is generated, an
EXEC is run to trim it down a bit before transferring (TFTPing) the
file to TPF. By default, the listing file is currently taken from
/tmp/lst on the TPF system.
|
