This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: GDB source structure
- From: Michael Snyder <Michael dot Snyder at palmsource dot com>
- To: Veeru (àààà) <misterveeru at gmail dot com>
- Cc: gdb at sourceware dot org
- Date: Fri, 01 Sep 2006 13:57:16 -0700
- Subject: Re: GDB source structure
- References: <ee4c53600609011321k5a7a538fp933250cc13bb58d6@mail.gmail.com> <ee4c53600609011324u4170f512pe88c25064fca8579@mail.gmail.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