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 - the<b> run</b> menu controls how your program executes. it contains the following http://www.X-Hacker.org [<<Previous Entry] [^^Up^^] [Next Entry>>] [Menu] [About The Guide]
The Run menu controls how your program executes.  It contains the following
items.


Go
    Start or resume program execution.  Execution resumes at the current
    location and will not stop until a breakpoint is encountered, an error
    occurs, or your program terminates.

Run to Cursor
    Resume program execution until it executes the location of the cursor in
    the Source or Assembly window.  Execution will stop before the cursor
    position if a breakpoint is encountered or an error occurs.

Execute to
    Resume program execution until it executes a specified address.  You
    will be prompted to enter an address.  It can be the name of a function
    or an expression that resolves to a code address.  See
    Watcom Debugger Expression Handling.  In the dialog, you can click the
    Symbols...  button as a shortcut.  You can type a partial symbol name
    like foo and the Symbol button will show you a list of symbols that
    start with foo.  You can then choose one of these symbols by clicking on
    it or hitting ENTER.  Note that the first time you use the Symbols...
     in a debugging session, it will take a while as the debugger sorts the
    symbol table for the program.

    If your program encounters a breakpoint or an error occurs before the
    specified address is executed, your request to stop at the given address
    is ignored.

Step Over
    Trace a single source or assembly line depending on whether the source
    or assembly window is current.  Step Over will not step into any
    function calls.

Trace Into
    This is similar to Step Over except that it will step into any function
    calls.

Next Sequential
    Run until the program executes the next sequential source line or
    assembly instruction.  This is useful if the program is executing the
    last statement in a loop and you wish to execute until the loop
    terminates.  When using this command, be sure that the execution path
    will eventually execute the next statement or instruction.  If execution
    fails to reach this point then the program may continue to execute until
    completion.  This situation is like setting a breakpoint at a statement
    or assembly instruction which will never be executed and then issuing a
    GO command.  In this situation, the application would execute until an
    error occurred or another breakpoint was encountered.

Until Return
    Resume program execution until the currently executing function returns.
     Execution terminates prior to this if an error occurs or a breakpoint
    is encountered.

Skip to Cursor
    Reposition the instruction pointer at the cursor position, "skipping"
    all instructions in between.  When you continue execution, the program
    continues from this point.  This is useful if you want to skip an
    offending line or re-execute something.  Use this menu item with
    caution.  If you skip to an instruction which is not in the current
    function or skip to code that expects a different program state, your
    program could crash.

Restart
    Restart your program from the beginning.  All breakpoints in your
    program will be preserved.  Breakpoints in DLLs will not be preserved.

Debug Startup
    Restart your program from the beginning but stop before system
    initialization.  Normally the debugger puts you at the main (fmain,
    winmain, etc.) entry point in your application.  This option will allow
    you to break much earlier in the initialization process.  This feature
    is useful for debugging run-time startup code, initializers, and
    constructors for static C++ objects.

    For DOS, Windows 3.x and Netware, the debugger will put you at the
    assembly entry point of your application (i.e., it doesn't run the
    "progstart" hook).

    Windows 3.x runs each DLL's startup code as it loads it, and the static
    DLLs are really loaded by the run-time startup code, so, to debug the
    startup code for a statically linked Windows 3.x DLL, you need to do the
    following.

     1. Select Debug Startup from the Run menu.

     2. Select On Image Load from the Break menu.  Type the name of the DLL
        in which you are interested.

     3. Select Go from the Run menu

    For OS/2 and Windows NT, the debugger will put you at a point after all
    DLLs have been loaded, but before any DLL initialization routines are
    called.  This enables you to set breakpoints in your statically
    referenced DLL's startup code.

    If you have hard-coded int3 instructions in your DLL startup, the
    debugger will skip them, unless you use Debug Startup from the Run menu.

    All breakpoints in your program will be preserved.  Breakpoints in DLLs
    will not be preserved.

Save
    Save the current debugging session to a file.  The file contains
    commands that will allow the debugger to play your debugging session
    back to its current point in a later session.  See The Replay Window.

Restore
    Restore a saved debugging session.  If you run the program with
    different input or if the program is a multi-threaded application, this
    option may not work properly since external factors may have affected
    program execution.  See The Replay Window.

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