From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6683 invoked by alias); 2 Sep 2006 15:28:28 -0000 Received: (qmail 6673 invoked by uid 22791); 2 Sep 2006 15:28:27 -0000 X-Spam-Check-By: sourceware.org Received: from nitzan.inter.net.il (HELO nitzan.inter.net.il) (192.114.186.20) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 02 Sep 2006 15:28:22 +0000 Received: from HOME-C4E4A596F7 (IGLD-80-230-70-232.inter.net.il [80.230.70.232]) by nitzan.inter.net.il (MOS 3.7.3-GA) with ESMTP id ENY35852 (AUTH halo1); Sat, 2 Sep 2006 18:28:14 +0300 (IDT) Date: Sat, 02 Sep 2006 15:28:00 -0000 Message-Id: From: Eli Zaretskii To: Michael Snyder CC: misterveeru@gmail.com, gdb@sourceware.org In-reply-to: <1157144236.4466.80.camel@localhost.localdomain> (message from Michael Snyder on Fri, 01 Sep 2006 13:57:16 -0700) Subject: Re: GDB source structure Reply-to: Eli Zaretskii References: <1157144236.4466.80.camel@localhost.localdomain> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-09/txt/msg00026.txt.bz2 > From: Michael Snyder > 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.