Source Tree Structure
The GDB source directory has a mostly flat structure—there are only a few subdirectories. A file’s name usually gives a hint as to what it does; for example, stabsread.c reads stabs, dwarf2read.c reads DWARF 2 (and later), etc. Files that are related to some common task have names that share common substrings. For example, *-thread.c files deal with debugging threads on various platforms; *read.c files deal with reading various kinds of symbol and object files; inf*.c files deal with direct control of the inferior program (GDB parlance for the program being debugged).
There are several dozens of files in the *-tdep.c family. ‘tdep’ (historically) stands for target-dependent code—each of these files implements debug support for a specific target architecture (SPARC, MIPS, etc.). Usually, only one of these will be used in a specific GDB configuration (sometimes two, closely related). Since these files are used when you configure GDB as a cross debugger (e.g., a GDB that runs on x86 but is configured to debug ARM code), all code in these files is host-independent. E.g., including host-specific headers, assuming host endianness, etc. in these files would be incorrect.
Similarly, there are many *-nat.c files, each one for native debugging on a specific system (e.g., sparc-linux-nat.c is for native debugging of SPARC machines running the Linux kernel). These files typically interface with the host's native debug API, like for example ptrace or the /proc filesystem.
The few subdirectories of the source tree are:
Code that implements CLI, the GDB Command-Line Interpreter. See Command Interpreter.
Code shared between GDB and GDBServer.
Code that implements the compile command.
Code for the GDB remote server, GDBServer.
Code related to the Guile bindings.
The GDB/MI, the GDB Machine Interface interpreter.
Code related to the Python bindings.
The GDB regression testsuite, further sub-divided in directories for various features.
Code for TUI, the GDB Text-mode full-screen User Interface. See TUI.
Unit tests that can be written in a self-contained way accessing public interfaces. Typically these are unit tests exercising generic utility code. You'll also find unit tests scattered around source files in other directories, close to the code they're exercising. Grep for "namespace selftests" to find them. You can run the unit tests with the "maint selftest" command. Running the regression testsuite also runs the unit tests.