wdbgos.gml

来自「开放源码的编译器open watcom 1.6.0版的源代码」· GML 代码 · 共 741 行 · 第 1/2 页

.chap *refid=vidoss Operating System Specifics
.*
.np
This section discusses the following topics:
.begnote $break
.note DOS Extender debugging
See the section entitled :HDREF refid='vid32'..
.note NLM debugging
See the section entitled :HDREF refid='vidnlm'..
.note Graphics programs
See the section entitled :HDREF refid='viddosg'..
.note Windows 3.x debugging
See the section entitled :HDREF refid='vidwin3'..
.note DLL debugging
See the section entitled :HDREF refid='viddll'..
.note Disabling 386/486 debug registers
See the section entitled :HDREF refid='viddosd'..
.note Linux debugging
See the section entitled :HDREF refid='vidlinux'..
.note QNX debugging
See the section entitled :HDREF refid='vidqnx'..
.endnote
.*
.section *refid=vid32 Debugging 32-bit DOS Extender Applications
.*
.np
.ix 'DOS extenders' 'debugging'
.ix '32-bit application debugging'
.ix 'debugging' '32-bit DOS applications'
The &dbgname supports debugging of 32-bit applications developed with
&watc32, &watf32, and assembly language.
.ix 'DOS extenders' 'debugging'
A DOS extender must be used to run the application.
The following DOS extenders are supported.
.begnote $break
.*
.note CauseWay DOS Extender
.ix 'DOS extenders' 'CauseWay'
.ix 'CauseWay'
a public domain DOS extender included in the &watc32 and &watf32 packages.
Note that this DOS extender is largely compatible with DOS/4GW and can often
be used interchangeably.
.*
.note DOS/4GW
.ix 'DOS extenders' 'DOS/4GW'
.ix 'DOS/4GW'
.ix 'DOS/4GW' 'version'
.ix 'Tenberry Software, Inc.'
a DOS extender from Tenberry Software, Inc.
DOS/4GW is a subset of Tenberry Software's DOS/4G product.
DOS/4GW is customized for use with &watc32 and &watf32 and is
included in these packages.
.*
.note 386|DOS-Extender
.ix 'DOS extenders' '386|DOS-Extender'
.ix '386|DOS-Extender'
.ix '386|DOS-Extender' 'version'
.ix 'Phar Lap Software, Inc.'
(version 2.2d or later) a DOS extender from Phar Lap Software, Inc.
.endnote
.*
.beglevel
.*
.section *refid=vidcw Debugging CauseWay 32-bit DOS Extender Applications
.*
.np
.ix 'CauseWay'
.ix 'CWSTUB.EXE'
.ix 'CW.TRP'
.ix 'trap file' 'CW.TRP'
When using the CauseWay DOS extender, the "CWSTUB.EXE" file must be located
in one of the directories listed in the DOS
.ev PATH
environment variable.
The "CWSTUB.EXE" file will usually be stored in the "BINW" directory
of the &company compiler package.
You must also use the
.sy TRap=CW
option.
The "CW.TRP" file will usually be stored in the "BINW" directory of
the &company compiler package.
You should ensure that this "BINW" directory is included in the DOS
.ev PATH
environment variable.
Otherwise, you must specify the full path name for the trap file.
.np
The help file "CWHELP.EXE" must also be located in one of the
directories listed in the DOS
.ev PATH
environment variable.
It will usually be stored in the "BINW" directory of the &company
compiler package.
.exam begin
C>&dbgcmd /trap=cw hello
  or
C>set &dbgcmd=/trap#cw
C>&dbgcmd hello
.exam end
.*
.*
.section *refid=vidrsi Debugging DOS/4G(W) 32-bit DOS Extender Applications
.*
.np
.ix 'Tenberry Software, Inc.' 'DOS4G.EXE'
.ix 'Tenberry Software, Inc.' 'DOS4GW.EXE'
.ix 'DOS4G.EXE'
.ix 'DOS4GW.EXE'
.ix 'RSI.TRP'
.ix 'trap file' 'RSI.TRP'
When using the Tenberry Software DOS extender, the "DOS4GW.EXE" or
"DOS4G.EXE" file must be located in one of the directories listed in
the DOS
.ev PATH
environment variable.
The "DOS4GW.EXE" file will usually be stored in the "BINW" directory
of the &company compiler package.
You must also use the
.sy TRap=RSI
option.
The "RSI.TRP" file will usually be stored in the "BINW" directory of
the &company compiler package.
You should ensure that this "BINW" directory is included in the DOS
.ev PATH
environment variable.
Otherwise, you must specify the full path name for the trap file.
.np
The help file "RSIHELP.EXP" must also be located in one of the
directories listed in the DOS
.ev PATH
environment variable.
It will usually be stored in the "BINW" directory of the &company
compiler package.
.exam begin
C>&dbgcmd /trap=rsi hello
  or
C>set &dbgcmd=/trap#rsi
C>&dbgcmd hello
.exam end
.*
.*
.section *refid=vidpls Debugging Phar Lap 32-bit DOS Extender Applications
.*
.np
.ix 'Phar Lap Software, Inc.' 'RUN386.EXE'
.ix 'RUN386.EXE'
.ix 'TNT.EXE'
.ix 'DBGLIB.REX'
.ix 'PLS.TRP'
.ix 'trap file' 'PLS.TRP'
.ix 'PLSHELP.EXP'
.ix 'PEDHELP.EXP'
When using the Phar Lap Software, Inc. DOS extender,
the "RUN386.EXE" (or "TNT.EXE"),
"DBGLIB.REX",
"PLSHELP.EXP",
and "PEDHELP.EXP"
files must be located in one of the directories listed in the DOS
.ev PATH
environment variable.
You must also use the
.sy TRap=PLS
option.
The "PLS.TRP", "PLSHELP.EXP" and "PEDHELP.EXP" files will usually be
stored in the "BINW" directory of the &company compiler package.
You should ensure that this "BINW" directory is included in the DOS
.ev PATH
environment variable.
Otherwise, you must specify the full path name for the trap file.
.np
.ix 'Phar Lap Software, Inc.' 'RUN386.EXE'
.ix 'RUN386.EXE'
.ix 'Phar Lap Software, Inc.' 'TNT.EXE'
.ix 'TNT.EXE'
Parameters are passed to the "RUN386" or "TNT" DOS extender using the
.sy TRap
option.
The entire parameter must be placed within braces.
The following example illustrates how to debug a Phar Lap application
passing the -maxreal switch to RUN386.EXE or TNT.EXE.
.exam begin
C>&dbgcmd /trap=pls;{-maxreal 512} hello
  or
C>set &dbgcmd=/trap#pls;{-maxreal 512}
C>&dbgcmd hello
.exam end
.*
.endlevel
.*
.section *refid=vidnlm Debugging a Novell NLM
.*
.np
.ix 'Novell NLM' 'debugging'
.ix 'NLM' 'debugging Novell'
.ix 'debugging' 'Novell NLM'
Novell NLM's may only be debugged remotely. You must use either the
serial, parallel, or Novell SPX link.
There are 5 NLM's distributed in the &company package.
The following table describes their use:
.millust begin
                NetWare 3.11/3.12       NetWare 4.01

Serial                                  serserv4.nlm
Parallel        parserv3.nlm            parserv4.nlm
SPX             novserv3.nlm            novserv4.nlm
.millust end
.np
To start remote debugging, you load one of the above NLMs at the NetWare
file server console. The debugger is then invoked as in any remote debugging
session.
See the chapter entitled :HDREF refid='vidrem'. for parameter
details.
See the appendix entitled :HDREF refid='vidwire'. for parallel/serial
cable details.
.np
For example, on a NetWare 4.01 server type:
.monoon
load novserv4
.monooff
.np
On a workstation, type:
.monoon
&dbgcmdup /tr=nov mynlm
.monooff
.np
Debugging information for every running NLM is available. You can
debug any NLM in the system as if it were part of your application, as
long as you created it with debug information. If the NLM does not
have Watcom style debugging information, the debugger will attempt to
use any debugging information created by Novell's linker (NLMLINK).
.*
.section *refid=viddosg Debugging Graphics Applications
.*
.np
.ix 'graphics applications' 'debugging'
When debugging a graphics application, there are a number of &dbgname
command line options that could be specified depending on your
situation.
.autonote
.note
If you only have one monitor attached to your system, use the
.sy Swap
option.
The
.sy Swap
option specifies that the application's screen memory and the
debugger's screen memory are to be swapped back and forth using a
single page.
.note
If you have two monitors attached to your system then the
.sy Two
and
.sy Monochrome
options should be used.
The
.sy Two
option specifies that a second monitor is connected to the system.
Note that if the monitor type (
.ct
.sy Monochrome,
.sy Color,
.sy Colour,
.sy Ega43,
.sy Vga50
.ct )
is not specified then the monitor that is not currently being
used is selected for the debugger's screen.
If you specify
.sy Monochrome
then the monochrome monitor will be used for the debugger's screen.
.note
If you are debugging the graphics application using a second personal
computer and the remote debugging feature of the &dbgname then the
choice of display and operation mode for the &dbgname is
irrelevant. If one system is equipped with a graphics display and the
other with a monochrome display then you will undoubtedly use the
system equipped with the monochrome display to run the &dbgname..
.endnote
.*
.section *refid=vidwin3 Debugging Windows 3.x Applications
.*
.np
.ix 'Windows' 'Microsoft'
.ix 'Windows 3.x' 'Microsoft'
.ix 'debugging' 'windows applications'
Both a character mode and a GUI debugger are supplied that run in the
Windows environment. You must choose which of these debuggers you are
going to use. They both have advantages and disadvantages. When your
application is suspended, the GUI and character mode debuggers behave
differently. The GUI debugger allows other applications to continue
running. The character mode debugger does not. Although the GUI
debugger has a much nicer looking user interface, you should not use
it under some circumstances. You can always use the character mode
debugger. You should be aware of the following restrictions:
.autopoint
.point
If you are trying to debug an applications that uses DDE you should
.bi not
use the GUI debugger.
.point
Do
.bi not
try to use the GUI debugger to debug system modal dialogs.
.point
If you hit a break-point in a dialog callback procedure or in your
window procedure when it is receiving certain events (e.g.,
WM_MENUSELECT), the GUI debugger will lock input to itself.
When this happens, you will not be able to switch away from the
debugger, and no other application will repaint themselves. When this
happens, pop-up menus will not draw correctly and you will have to use
the
.mm Action
menu instead.  You should not try to quit the debugger when it is in this
state.
.point
Do
.bi not
try to use either of the Windows debuggers in a seamless Win-OS/2 session.
.endpoint
.np
If you find that the Windows debugger starts too slowly, try using the
.sy DIp=DWARF
option. This prevents the debugger from searching each DLL in the
system for debugging information. It will start up faster, but you
will not be able to see the name of the Windows API calls.
.np
To start the &dbgname., select the program group in which you have
installed the &dbgname..
One of the icons presented is used to start the debugger.
Double-click on the &dbgname icon.
.np
You can make special versions of the &dbgname icon using
.menuref 'Properties' 'File'
of the Windows "Program Manager".
For example, you can add any options you wish to the "Command Line"
field of the "Properties" window.
When you click on the newly created icon, the options specified in the
"Command Line" field are the defaults.
As long as no executable file name was specified in the "Command Line"
field, the &dbgname will present its prompt window.
In the prompt window, you can specify an executable file name and arguments.
.np
If you are debugging the same program over and over again, you might
wish to create an icon that includes the name of the file you wish to
debug in the "Command Line" field.
Each time you click on that icon, the &dbgname is started and it
automatically loads the program you wish to debug.
.*
.section *refid=viddll Debugging Dynamic Link Libraries
.*
.np
.ix 'debugging DLLs'
.ix 'DLL' 'debugging'
The debugger automatically detects all DLLs that your application
references when it loads the application.
When your program loads a DLL dynamically, the debugger detects this
as well.
If you have created your DLL with debugging information,
you can debug it just as if it were part of your application.
Even if it does not have debugging information, the debugger will
process system information to make the DLL entry point names visible.
There are a few limitations:
.autopoint
.point
You cannot debug your DLL initialization code.  This is the
first routine that the operating system runs when it loads the DLL.
This is not normally a problem, since most DLLs do not do much in the
way of initialization.
.point
When a DLL is loaded dynamically, its debugging information may not
be available immediately.  Try tracing a few instructions and it will
appear.