Re: GDB source structure

Eli Zaretskii
2006-09-02T15:28:28Z

> From: Michael Snyder <Michael.Snyder@palmsource.com>
> Cc: gdb@sourceware.org
> Date: Fri, 01 Sep 2006 13:57:16 -0700
>
> > So, is there a method to the file structure?
>
> Well... you be the judge.
>
> It's mostly flat -- only in a few cases have related files been
> dropped into a subdirectory. A file's name should give you some
> hint as to what it does -- stabsread.c reads stabs, dwarfread.c
> reads dwarf etc.
>
> There are a lot of files, because gdb does a lot of things.
>
> There are some clusters. *-thread.c deals with debugging threads
> on various platforms. *read.c (| grep -v thread) deals with
> reading various kinds of symbol and object files. inf*.c deals
> with direct control of the "inferior program" by gdb (jargon for
> the program being debugged.
>
> There are 92 files in the family *-tdep.c. tdep stands for
> target dependant 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).
>
> Similarly, there are 56 *-nat.c files, each related to
> debugging on a specific native system (eg. sparc-linux-nat.c).

Thanks, Michael. Inspired by this, I added a new section to
gdbint.texinfo. See my message on gdb-patches.