From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7125 invoked by alias); 1 Sep 2006 20:57:24 -0000 Received: (qmail 7006 invoked by uid 22791); 1 Sep 2006 20:57:23 -0000 X-Spam-Check-By: sourceware.org Received: from mx2.palmsource.com (HELO mx2.palmsource.com) (12.7.175.14) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 01 Sep 2006 20:57:21 +0000 Received: from localhost (localhost [127.0.0.1]) by localhost.domain.tld (Postfix) with ESMTP id 8336E26E8E; Fri, 1 Sep 2006 13:57:19 -0700 (PDT) Received: from mx2.palmsource.com ([127.0.0.1]) by localhost (mx2.palmsource.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 22503-01-16; Fri, 1 Sep 2006 13:57:18 -0700 (PDT) Received: from ussunex01.palmsource.com (unknown [192.168.101.9]) by mx2.palmsource.com (Postfix) with ESMTP id 58BE426E62; Fri, 1 Sep 2006 13:57:18 -0700 (PDT) Received: from 192.168.92.59 ([192.168.92.59]) by ussunex01.palmsource.com ([192.168.101.9]) via Exchange Front-End Server owa.palmsource.com ([10.0.20.17]) with Microsoft Exchange Server HTTP-DAV ; Fri, 1 Sep 2006 20:57:17 +0000 Received: from svmsnyderlnx by owa.palmsource.com; 01 Sep 2006 13:57:16 -0700 Subject: Re: GDB source structure From: Michael Snyder To: Veeru =?UTF-8?Q?=28=E0=A4=B5=E0=A5=80=E0=A4=B1=E0=A5=82=29?= Cc: gdb@sourceware.org In-Reply-To: References: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 01 Sep 2006 20:57:00 -0000 Message-Id: <1157144236.4466.80.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 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/msg00020.txt.bz2 On Fri, 2006-09-01 at 13:24 -0700, Veeru (=E0=A4=B5=E0=A5=80=E0=A4=B1=E0=A5= =82) wrote: > Hi Dan, >=20 > 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. >=20 >=20 > 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. >=20 > I do believe though that if there is a method to the madness, it is up > to the newbies to learn it. >=20 > 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=20 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.=20=20 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=20 reading various kinds of symbol and object files. inf*.c deals=20 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=20 debugging on a specific native system (eg. sparc-linux-nat.c). HTH,=20 Michael