Retro video games delivered to your door every month!
Click above to get retro games delivered to your door ever month!
X-Hacker.org- Watcom Debugger Guide - regardless of the programming language that was used to code the modules of http://www.X-Hacker.org [<<Previous Entry] [^^Up^^] [Next Entry>>] [Menu] [About The Guide]
Regardless of the programming language that was used to code the modules of
an application, the names of variables and routines will be available to the
debugger (provided that the appropriate symbolic debugging information has
been included with the application's execution module).  The debugger does
not restrict the way in which names are used in expressions.  A name could
represent a variable but it could also represent the entry point into a
routine.

The syntax of a symbol name reference is quite complicated.

      
     [[[image]@][module]@][routine_name.]symbol_name

Generally, an application will consist of many modules which were compiled
separately.  The current image is the one containing the module which is
currently executing.  The current module is the one containing the source
lines currently under examination in the Source or Assembly window.  By
default, the Source window's title line contains the current module name.
 The current routine is the one containing the source line at which
execution is currently paused.

The following are examples of references to symbol names.

Example:

     symbol_name
     main
     WinMain
     FMAIN
     printf
     LIB$G_OPEN
     stdin

If the symbol does not exist in the current scope then it must be qualified
with its routine name.  Generally, these are variables that are local to a
particular routine.

Example:

     routine_name.symbol_name
     main.curr_time
     main.tyme
     SUB1.X
     SUB2.X

If the symbol is not externally defined and it does not exist in the current
module then it may be qualified with its module name.  In the C and C++
programming languages, we can define a variable that is global to a module
but known only to that module ("static" storage class).

Example:

     static char *NarrowTitle = { "Su Mo Tu We Th Fr Sa" };

In the above example, "NarrowTitle" is global to the module "calendar".  If
the current module is not "calendar" then the module name can be used to
qualify the symbol as shown in the following example.

Example:

     calendar@NarrowTitle

If the symbol is local to a routine that is not in the current module then
it must be qualified with its module name and routine name.

Example:

     module_name@routine_name.symbol_name
     calendar@main.curr_time
     calendar@main.tyme
     subs@SUB1.X
     subs@SUB2.X

If the symbol is local to an image that is not in the current executable
then it must be fully qualified with the image name.

Example:

     prog_name@@routine_name
     prog_name@module_name@routine_name
     prog_name@module_name@routine_name.symbol_name
     dll_name@calendar@main.curr_time
     dll_name@calendar@main.tyme
     program@subs@SUB1.X
     program@subs@SUB2.X

There is a special case for the primary executable image.  This is the name
of the program you specified when you started the debugger.  You can
reference it by omitting the image name.  The following examples all refer
to symbols in the primary executable image:

Example:

     @@WinMain
     @module@WinMain
     @@routine.symbol

In the FORTRAN 77 programming language, all variables (arguments, local
variables, COMMON block variables) are available to the subprogram in which
they are defined or referenced.  The same symbol name can be used in more
than one subprogram.  If it is a local variable, it represents a different
variable in each subprogram.  If it is an argument, it may represent a
different variable in each subprogram.  If it is a variable in a COMMON
block, it represents the same variable in each subprogram where the COMMON
block is defined.

Example:

     SUBROUTINE SUB1( X )
     REAL Y
     COMMON /BLK/ Z
         .
         .
         .
     END
     SUBROUTINE SUB2( X )
     REAL Y
     COMMON /BLK/ Z
         .
         .
         .
     END

In the above example, "X" is an argument and need not refer to the same
variable in the calling subprogram.

Example:

     CALL SUB1( A )
     CALL SUB2( B )

The variable "Y" is a different variable in each of "SUB1" and "SUB2".  The
COMMON block variable "Z" refers to the same variable in each of "SUB1" and
"SUB2" (different names for "Z" could have been used).  To refer to "X",
"Y", or "Z" in the subprogram "SUB2", you would specify "SUB2.X", "SUB2.Y",
or "SUB2.Z".  If "SUB2" was in the module "MOD" and it is not the current
module, you would specify "MOD@SUB2.X", "MOD@SUB2.Y", or "MOD@SUB2.Z".

Note:
    Global and local symbol name debugging information is included in an
    executable image if you request it of the linker.  However, local symbol
    information must be present in your object files.  The WATCOM C, C++ and
    FORTRAN 77 compilers can include local symbol debugging information in
    object files by specifying the appropriate compiler option.  See
    Preparing a Program to be Debugged.

Online resources provided by: http://www.X-Hacker.org --- NG 2 HTML conversion by Dave Pearson