GDB source structure

GDB source structure

[Veeru (वीऱू)]

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?

Thanx!
Veeru
--
> On Fri, Sep 01, 2006 at 11:04:22AM -0700, Veeru wrote:
>> Hi!
>>
>> I have been looking at gdb lately. I come from a background of large system

>> software projects like compilers. I find it difficult at times to navigate
>> through  the code simply because we appear to have everything within one
>> directory.
>
> If you have questions about GDB, please use the GDB mailing list at

> sourceware.org.
>  http://www.eyrie.org/~eagle/faqs/questions.html
>
>> Have we considered code refactoring using sub-directories, especially to

>> separate out architectures and operating systems in a way that one can only
>> concentrate on the stack he wants?
>
> We've always decided in the past that it was not worth the
> inconvenience and confusion of reorganizing.

>
> --
> Daniel Jacobowitz
> CodeSourcery

Re: GDB source structure

[Daniel Jacobowitz]

On Fri, Sep 01, 2006 at 01:24:19PM -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.

Yes, it is.  It's extremely consistent.  The files which are specific
to an architecture or OS are named after that architecture or OS.
I don't know of any exceptions.


-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB source structure

[Michael Snyder]

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

Re: GDB source structure

[Eli Zaretskii]

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