Re: GDB source structure

[Michael Snyder <Michael.Snyder@palmsource.com>]

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