wdbgos.gml

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

.point
If you restart an application, you will lose any break points that
you had set in dynamically loaded DLLs.  You need to trace back
over the call to LoadModule or DOSLoadModule and re-set these
break points.
.endpoint
.*
.section *refid=viddosd Disabling Use of 386/486 Debug Registers
.*
.np
.ix 'debug registers' 'disabling'
.ix 'debug registers' 'using'
It may be necessary to prevent the &dbgname from using the 386/486
Debug Registers (a hardware feature used to assist debugging).
This situation arises with certain DOS control programs that do not
properly manage Debug Registers.
If the &dbgname fails upon startup on a 386/486 system, it is a good
indication that use of the Debug Registers must be disabled.
With "STD.TRP", the trap file parameter "d" may be specified to
disable the use of Debug Registers.
The following example illustrates the specification of the "d" trap
file parameter.
.exam begin
C>&dbgcmd /trap=std;d calendar
.exam end
.*
.section *refid=vidlinux Debugging Under Linux
.*
.np
.ix 'debugging under Linux'
.ix 'Linux' 'debugging'
.ix '.wdrc'
.ix 'Linux' 'customization'
When the debugger starts up, it will attempt to open the
initialization file
.mono .wdrc
provided that you have not specified the
.sy Invoke
command line option.
It looks for this file in all the usual places (
.ct
.ev CWD,
.ev WD_PATH,
.mono /opt/watcom/wd
.ct ).
This file normally contains your customization commands.
If it is found, it is processed as the default configuration file.
You would normally place this file in your home directory.
.np
If the file does not exist, the debugger then looks for
the
.mono &dbgcmd..&dbgsuff
file.
.np
If you do not want the debugger to use the
.mono .wdrc
file then you can do one of two things &mdash. make sure that it
cannot be located (e.g., delete it) or use the
.sy Invoke
command line option (you could specify the
.mono &dbgcmd..&dbgsuff
file as the target).
.np
The supplied version of the
.mono &dbgcmd..&dbgsuff
file contains an "invoke" command referencing the file
.mono setup.&dbgsuff..
This file, in turn, contains a "configfile" command and "invoke"
commands referencing other command files.
The "configfile" command marks
.mono setup.&dbgsuff
as the default file name to use when the debugger writes out the
current configuration.
.np
The following section entitled :HDREF refid='vidlinuxs'. describes the
search order for debugger files under Linux.
.*
.beglevel
.*
.section *refid=vidlinuxs Search Order for &dbgname Support Files under Linux
.*
.np
There are several supporting files provided with the &dbgname..
These files fall into five categories.
.ix 'support files' 'dbg'
.ix 'support files' 'trp'
.ix 'support files' 'prs'
.ix 'support files' 'hlp'
.ix 'support files' 'sym'
.autonote
.note
&dbgname command files (files with the ".&dbgsuff" suffix).
.note
&dbgname trap files (files with the ".trp" suffix).
.note
&dbgname parser files (files with the ".prs" suffix).
.note
&dbgname help files (files with the ".hlp" suffix).
.note
&dbgname symbolic debugging information files (files with the ".sym"
suffix).
.endnote
.np
.ix 'support files' 'search order'
.ix 'search order' 'Linux'
The search order for &dbgname support files is as follows:
.autopoint
.point
the current directory,
.point
the paths listed in the
.ev &dbgcmdup._PATH
environment variable,
.point
the path listed in the
.ev HOME
environment variable
.point
the directory where &dbgname was started from
.point
"../wd" directory relative to the directory where &dbgname was started
from, and, finally,
.point
the "/opt/watcom/wd" directory.
.endpoint
.np
You should note the following when using the remote debugging feature
of the &dbgname..
When the
.sy REMotefiles
option is specified, the debugger also attempts to locate the &dbgname's
support files (command files, trap files, etc.) on the task machine.
.*
.endlevel
.*
.section *refid=vidqnx Debugging Under QNX
.*
.np
.ix 'debugging under QNX'
.ix 'QNX' 'debugging'
.ix '.wdrc'
.ix 'QNX' 'customization'
When the debugger starts up, it will attempt to open the
initialization file
.mono .wdrc
provided that you have not specified the
.sy Invoke
command line option.
It looks for this file in all the usual places (
.ct
.ev CWD,
.ev WD_PATH,
.mono /usr/watcom/<ver>/wd,
.mono /usr/watcom/wd
.ct ).
This file normally contains your customization commands.
If it is found, it is processed as the default configuration file.
You would normally place this file in your home directory.
.np
If the file does not exist, the debugger then looks for
the
.mono &dbgcmd..&dbgsuff
file.
.np
If you do not want the debugger to use the
.mono .wdrc
file then you can do one of two things &mdash. make sure that it
cannot be located (e.g., delete it) or use the
.sy Invoke
command line option (you could specify the
.mono &dbgcmd..&dbgsuff
file as the target).
.np
The supplied version of the
.mono &dbgcmd..&dbgsuff
file contains an "invoke" command referencing the file
.mono setup.&dbgsuff..
This file, in turn, contains a "configfile" command and "invoke"
commands referencing other command files.
The "configfile" command marks
.mono setup.&dbgsuff
as the default file name to use when the debugger writes out the
current configuration.
.np
The following section entitled :HDREF refid='vidpmd'. describes the
use of the debugger with the Postmortem dump facility.
The following section entitled :HDREF refid='vidqnxs'. describes the
search order for debugger files under QNX.
.*
.beglevel
.*
.section *refid=vidpmd Debugging Under QNX Using the Postmortem Dump Facility
.*
.np
.ix 'postmortem dump' 'QNX'
.ix 'debugging' 'postmortem dump under QNX'
A limited form of debugging of an application that has terminated and
produced a postmortem dump can be done under QNX.
.ix 'dumper'
.ix 'dumper command'
In order to use this feature, you must start the QNX "dumper" program.
.mbigbox
dumper [-d path] [-p pid] &
.embigbox
.begnote
.note dumper
is the program name for the QNX postmortem dump program.
.note -d path
The name of the directory in which postmortem dumps are written.
If not specified, the default is the user's home directory.
.note -p pid
Save a dump file for this process if it terminates for any reason.
Do not save a dump file for any other process.
.note &
must be specified so that the shell is rejoined.
.endnote
.exam begin
$ dumper &
$ dumper -d /usr/fred/dump_area &
.exam end
.np
Whenever a program terminates abnormally, a dump of the current state
of the program in memory is written to disk.
The dump file name is the same as the program name with a
.bd ~.dmp
extension.
For example, if the program name is
.bd a.out
then the dump will be written to the
.bd /home/userid/a.out.dmp
file.
.np
You can use the
.sy -d
option of the dumper program to force all dumps into a single directory
rather than into the invoking user's home directory.
.np
The
.sy -p
option lets you monitor a particular process.
You can run multiple copies of the dumper program, each monitoring a
different process.
.np
If the &dbgname was being used to debug the program at the time that
it abnormally terminated then the dump is written to the user's home
directory provided that the
.sy -d
option was not used.
.np
To examine the contents of the postmortem dump, the &dbgname may be
used.
.ix 'trap file'
The interface between the &dbgname and the postmortem dump is
contained in a special "trap" file.
The trap file is specified to the &dbgname using the
.sy TRap
option.
.ix 'pmd.trp'
.ix 'trap file' 'pmd.trp'
.mbigbox
&dbgcmd -TRap=pmd[;i] [:sym_file] file_spec
.embigbox
.begnote
.note &dbgcmd
is the program name for the &dbgname..
.note -TRap=pmd[;i]
.ix 'TRap option'
must be specified when debugging an application that has
terminated and produced a postmortem dump.
The optional ";i" is specified when the modification date of the
original program file does not match the information contained in the
dumper file.
It indicates that the symbolic debugging information in the program file
may be out-of-date.
It instructs the &dbgname to ignore the date mismatch.
Depending on the shell that you are using, it may be necessary to place
the option specification in quotation marks if you include the optional
";i".
.exam begin
$ &dbgcmd "-trap=pmd;i" myapp
.exam end
.note sym_file
is an optional symbolic information file specification.
The specification must be preceded by a colon (":").
When specifying a symbol file name, a path such as "//5/etc/" may
be included.
For QNX, the default file suffix of the symbol file is ".sym".
.note file_spec
is the file name of the dumper file to be loaded into memory.
When specifying a file name, a path such as "//5/etc/" may be
included.
If a path is omitted, the &dbgname will first attempt to locate the
file in the current directory and, if not successful, attempt to
locate the file in the default dumper directory:
.bd /usr/dumps.
.endnote
.np
Basically, the &dbgname is fully functional when a postmortem dump is
examined.
However, there are some operations which are not allowed.
Among these are:
.autonote
.note
Task execution cannot be restarted using
.menuref 'Go' 'Run'
.dot
.note
A register can be modified for the purposes of expression evaluation.
You can choose
.menuref 'Go' 'Run'
to restore the register contents to their original postmortem state.
.note
Memory cannot be modified.
.note
Memory outside of regions owned by the program cannot always be examined.
.note
I/O ports cannot be examined.
.endnote
.*
.section *refid=vidqnxs Search Order for &dbgname Support Files under QNX
.*
.np
There are several supporting files provided with the &dbgname..
These files fall into five categories.
.ix 'support files' 'dbg'
.ix 'support files' 'trp'
.ix 'support files' 'prs'
.ix 'support files' 'hlp'
.ix 'support files' 'sym'
.autonote
.note
&dbgname command files (files with the ".&dbgsuff" suffix).
.note
&dbgname trap files (files with the ".trp" suffix).
.note
&dbgname parser files (files with the ".prs" suffix).
.note
&dbgname help files (files with the ".hlp" suffix).
.note
&dbgname symbolic debugging information files (files with the ".sym"
suffix).
.endnote
.np
.ix 'support files' 'search order'
.ix 'search order' 'QNX'
The search order for &dbgname support files is as follows:
.autopoint
.point
the current directory,
.point
the paths listed in the
.ev &dbgcmdup._PATH
environment variable,
.point
the path listed in the
.ev HOME
environment variable, and, finally,
.point
the "/usr/watcom/wd" directory.
.endpoint
.np
You should note the following when using the remote debugging feature
of the &dbgname..
When the
.sy REMotefiles
option is specified, the debugger also attempts to locate the &dbgname's
support files (command files, trap files, etc.) on the task machine.
.*
.endlevel