From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21577 invoked by alias); 18 Oct 2002 21:12:47 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 21566 invoked from network); 18 Oct 2002 21:12:46 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 18 Oct 2002 21:12:46 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id g9IKpkw25547 for ; Fri, 18 Oct 2002 16:51:46 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id g9ILCkf13678 for ; Fri, 18 Oct 2002 17:12:46 -0400 Received: from localhost.redhat.com (IDENT:cYbOCgHj/AinxyLs3lzRgzV+tPYBexRN@tooth.toronto.redhat.com [172.16.14.29]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id g9ILCiT10200; Fri, 18 Oct 2002 17:12:44 -0400 Received: by localhost.redhat.com (Postfix, from userid 469) id 2FA52FF79; Fri, 18 Oct 2002 17:10:04 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15792.30892.69140.402056@localhost.redhat.com> Date: Fri, 18 Oct 2002 14:12:00 -0000 To: David Carlton Cc: gdb-patches@sources.redhat.com, Jim Blandy , Elena Zannoni Subject: Re: [rfc] split up symtab.h In-Reply-To: References: X-SW-Source: 2002-10/txt/msg00307.txt.bz2 David Carlton writes: > I'm sick of having to recompile half of GDB every time I touch > symtab.h. There's lots of different things in that file; it's > included in 137 different places (counting only the gdb directory, not > gdb/mi, etc.), but there's no one thing that it defines that is used > in more than 71 places, and a lot of things that it defines are used > in a lot fewer places than that. > I see your point. But I have to agree with Kevin about the tangled web we could be weaving. Maybe we could start with a little cleanup. Are all the things exported by symtab.h actually used? And vice versa, are the files including symtab.h actually needing it? I found a few times that some dependencies were left in place after some code which needed them had been deleted, etc. Elena > Here's what is defined in symtab.h, together with the number of .c > files that each construct is mentioned in. (I've produced this > information with a naive use of grep/cut/uniq, so it could be off: the > main problem is that, say, every use of 'struct blockvector' counts as > a use of 'struct block'. Then again, what file would use 'struct > blockvector' without using 'struct block'?) > > struct general_symbol_info (1) > struct minimal_symbol (71) > struct blockvector (13) > struct block (38) > struct range_list (2) > struct alias_list (2) > struct symbol (62) > struct partial_symbol (10) > struct sourcevector (0) > struct linetable_entry (6) > struct linetable (9) > struct source (0) > struct section_offsets (20) > struct symtab (65) > struct partial_symtab (16) > struct symtab_and_line (39) > struct symtabs_and_lines (9) > enum exception_event_kind (4) > struct exception_event_record (4) > struct symbol_search (1) > > There are, of course, many function declarations in there as well. > > Of course, these numbers are still pretty large, but having my > compilation numbers cut from 137 files to 38 or 62 files or whatever > would help a lot. (And yes, I realize that 137 isn't accurate: many > of the files are target-specific, so I'm not really recompiling 137 > files every time I touch symtab.h.) > > I haven't generated complete correlation data; some of what I have > generated is pretty interesting, though. For example, while it's not > surprising every file that mentions 'struct partial_symbol' also > mentions 'struct symbol', I was a little surprised to see that 41 > files mention both 'struct symbol' and 'struct minimal_symbol', 21 > files mention only the former, and 30 files mention only the latter. > > Here's one possible way to split things up into new files: > > gensym.h: > > struct general_symbol_info (1) > > minsyms.h: > > struct minimal_symbol (71) > > block.h: > > struct blockvector (13) > struct block (38) > > symbol.h: > > struct range_list (2) > struct alias_list (2) > struct symbol (62) > namespace_enum (5) > enum address_class (4) > > psymbol.h: > > struct partial_symbol (10) > > linetable.h: > > struct linetable_entry (6) > struct linetable (9) > > symtab.h: > > struct symtab (65) > > psymtab.h: > > struct partial_symtab (16) > > sal.h: > > struct symtab_and_line (39) > struct symtabs_and_lines (9) > > exception.h: > > enum exception_event_kind (4) > struct exception_event_record (4) > > section.h: > > struct section_offsets (20) > > Move to symtab.c: > > struct symbol_search (1) > > Delete entirely (where are these used?): > > struct sourcevector (0) > struct source (0) > > I haven't looked at where function declarations go; I expect that, in > practice, it'll be pretty obvious which ones go where. (Though there > are a few weirdos; where does {set_}main_name go?) > > > Anyways, if anybody else is similarly annoyed with symtab.h then I'll > try to split things up and make a more concrete RFA in a bit. > > David Carlton > carlton@math.stanford.edu