This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GDB source structure


> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]