From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23471 invoked by alias); 8 Oct 2002 20:14:16 -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 23464 invoked from network); 8 Oct 2002 20:14:15 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 8 Oct 2002 20:14:15 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id g98KEE307888; Tue, 8 Oct 2002 13:14:14 -0700 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: gdb-patches@sources.redhat.com Subject: [rfc] split up symtab.h Cc: Jim Blandy , Elena Zannoni From: David Carlton Date: Tue, 08 Oct 2002 13:14:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-10/txt/msg00182.txt.bz2 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) 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