This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 00/21] struct symtab split part 2
- From: Simon Marchi <simon dot marchi at ericsson dot com>
- To: <gdb-patches at sourceware dot org>
- Date: Thu, 13 Nov 2014 11:13:22 -0500
- Subject: Re: [PATCH 00/21] struct symtab split part 2
- Authentication-results: sourceware.org; auth=none
- References: <m3ppcrz2pf dot fsf at sspiff dot org>
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.