To run gdb in command mode there are 3 alternatives ways to fire it up depending on the state of the program you want to debug.
gdb Zoo.exeThis is the way most people run a debugger; they want to start and run the program to be debugged from within the debugger.
Caution: when gdb runs your job it will do so in a separate shell, it is like you have logged in again. So if your job needs any special environmental variables set, make sure that they are in your login scripts e.g. .cshrc.
gdb Zoo.exe 1234where 1234 is the process id of a running Zoo.exe. gdb attaches to the process so that you can examine and control it. It can be useful if a running job starts behaving oddly or if the job is running in some special environment that would not be reproduced if you ran the debugger from scratch.
gdb Zoo.exe core_filewhere core_file is the name of the core file (usually ``core''). When a program cashes it can produce a memory dump into a file. gdb can examine this dump to provide a postmortem of the job so you can examine the state when it died, However, you cannot bring it back from the dead and start it running again!