Re: [rfc] split up symtab.h

[Elena Zannoni <ezannoni at redhat dot com>]

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