This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfc] split up symtab.h
- From: Michael Snyder <msnyder at redhat dot com>
- To: David Carlton <carlton at math dot stanford dot edu>
- Cc: gdb-patches at sources dot redhat dot com, Jim Blandy <jimb at red-bean dot com>, Elena Zannoni <ezannoni at redhat dot com>
- Date: Tue, 08 Oct 2002 15:09:58 -0700
- Subject: Re: [rfc] split up symtab.h
- Organization: Red Hat, Inc.
- References: <ro1bs64lmcp.fsf@jackfruit.Stanford.EDU>
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