Re: GDB source structure

Michael Snyder
2006-09-01T20:57:24Z

On Fri, 2006-09-01 at 13:24 -0700, Veeru (वीऱू) wrote:
> Hi Dan,
>
> The set of files is reaching close to 600 in number in that directory.
> At this point,
> even doing an ls is difficult, forget separating out different
> architectures and operating systems.
> Some file names have the architecture or OS name in them but even that
> usage is not consistent.
>
>
> It would be far easier for folks interested in only a part of the
> distribution to be able to focus
> on the files that they are interested in.
>
> I do believe though that if there is a method to the madness, it is up
> to the newbies to learn it.
>
> 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).

HTH,
Michael