Re: [PATCH 00/21] struct symtab split part 2

[Simon Marchi <simon.marchi@ericsson.com>]

On 2014-11-13 07:48 AM, Doug Evans wrote:
> Hi.
> 
> This is part 2 of a patch set to split up struct symtab.
> Part 1 was here: https://sourceware.org/ml/gdb-patches/2014-11/msg00193.html
> 
> Currently "symtabs" in gdb are stored as a single linked list of
> struct symtab that contains both symbol symtabs (the blockvectors)
> and file symtabs (the linetables).
> 
> This has led to confusion, bugs, and performance issues.
> 
> This patch is conceptually very simple: split struct symtab into
> two pieces: one part containing things common across the entire
> compilation unit, and one part containing things specific to each
> source file.
> 
> Example.
> For the case of a program built out of these files:
> 
> foo.c
>   foo1.h
>   foo2.h
> bar.c
>   foo1.h
>   bar.h
> 
> Today we have a single list of struct symtabs:
> 
> objfile -> foo.c -> foo1.h -> foo2.h -> bar.c -> foo1.h -> bar.h -> NULL
> 
> where "->" means the "next" pointer in struct symtab.
> 
> With this patch, that turns into:
> 
> objfile -> foo.c(cu) -> bar.c(cu) -> NULL
>             |            |
>             v            v
>            foo.c        bar.c
>             |            |
>             v            v
>            foo1.h       foo1.h
>             |            |
>             v            v
>            foo2.h       bar.h
>             |            |
>             v            v
>            NULL         NULL
> 
> where "foo.c(cu)" and "bar.c(cu)" are struct compunit_symtab objects,
> and the files foo.c, etc. are struct symtab objects.
> 
> So now, for example, when we want to iterate over all blockvectors
> we can now just iterate over the compunit_symtab list.
> 
> Plus a lot of the data that was either unused or replicated for each
> symtab in a compilation unit now lives in struct compunit_symtab.
> E.g., the objfile pointer, the producer string, etc.
> I thought of moving "language" out of struct symtab but there is
> logic to try to compute the language based on previously seen files,
> and I think that's best left as is for now.
> With my standard monster benchmark with -readnow (which I can't actually
> do, but based on my calculations), whereas today the list requires
> 77MB to store all the struct symtabs, it now only requires 37MB.
> A modest space savings given the gigabytes needed for all the debug info,
> etc.  Still, it's nice.  Plus, whereas today we create a copy of dirname
> for each source file symtab in a compilation unit, we now only create one
> for the compunit.

Hi Doug,

As someone who never quite understood who the symtab mechanism worked in gdb,
I welcome this change very much It makes the data structure a bit more
self-descriptive, which in turn helps understanding the algorithms used.

That lovely ascii art chart makes things very clear, and I would even suggest
including it somewhere in the code (symtab.h I guess).

Thanks a lot for your work.