Re: [rfc] split up symtab.h

[Michael Snyder <msnyder@redhat.com>]

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