Please refer to GDB documenation for a list of GDB commands and explanations of their usage. GDB documenation can be accessed by the command
info gdb
GDB has online help also. The GDB command help gives a short description of a command name or topic name given as an argument.

Killing or terminating GDB

If GDB does not respond to user input, you can kill it. If the test kernel was controlled by kgdb when gdb was killed, a new GDB can be started and it can be connected to kgdb. Otherwise you'll first need to make the test kernel drop into kgdb. To do this send an ascii 3 character into the serial line. An example of a command which does that is:
echo -e "\003" > /dev/ttyS1
When GDB has printed a command prompt, you can quit it and start a new GDB and connect to KGDB immediately.

GDB removes all breakpoints before presenting a command prompt. Hence if a new GDB is started, there will be no breakpoints in the kernel. You'll need to add all the breakpoints again. However, if a running GDB was killed after adding some breakpoints, they will remain in the kernel. New GDB will not know about those breakpoints. Hence if one of these breakpoints is hit during subsequent execution, GDB will not be able to handle it properly. Since a breakpoint modifies code, execution after this point is unpredictable. A hardware reset is recommended in this case. KGDB versions 1.6 onwards maintain breakpoints within the stub itself, hence don't show this problem.

KGDB hardware watchpoints are handled by KGDB stub and GDB does not know anything about them. Hence there are no issues with watchpoints if a GDB is killed.

Test machine reboot