From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7479 invoked by alias); 8 Oct 2002 22:11:26 -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 7429 invoked from network); 8 Oct 2002 22:11:24 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 8 Oct 2002 22:11:24 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id g98LpiX21495 for ; Tue, 8 Oct 2002 17:51:44 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id g98MBCl00878; Tue, 8 Oct 2002 18:11:13 -0400 Received: from redhat.com (dhcp-172-16-25-149.sfbay.redhat.com [172.16.25.149]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id g98MB8N25682; Tue, 8 Oct 2002 15:11:08 -0700 Message-ID: <3DA357B6.B37C5BC7@redhat.com> Date: Tue, 08 Oct 2002 15:11:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: David Carlton CC: gdb-patches@sources.redhat.com, Jim Blandy , Elena Zannoni Subject: Re: [rfc] split up symtab.h References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-10/txt/msg00185.txt.bz2 David Carlton wrote: > > 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. > > 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) Careful. Struct general_symbol_info is mentioned in LOTS of places... indirectly, thru uses of the macros SYMBOL_NAME, SYMBOL_TYPE, etc. > 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