[patch] Fix symtab/14601

Doug Evans dje@google.com
Fri Sep 21 19:18:00 GMT 2012


On Fri, Sep 21, 2012 at 9:38 AM, Tom Tromey <tromey@redhat.com> wrote:
> Doug> Not all code paths to handle DW_TAG_imported_{declaration,module}
> Doug> ensure using_directives is reset to NULL.
> Doug> This patch fixes things by "going with the flow" and resetting
> Doug> using_directives to NULL in buildsym_init along with the others.
>
> What code paths result in the bad behavior?
> I think this patch is fine but I wonder if the underlying bug has other
> possible bad effects.

The only code that currently resets using_directives to NULL is
finish_block_internal and push_context.
dwarf2read.c resets it to the previous value in read_func_scope and
read_lexical_block_scope, but that doesn't guarantee the "the next
guy" that needs to expand symbols (i.e. invoke the buildsym machinery)
will have using_directives == NULL at the start.
Note that this is counter to how buildsym is generally set up.
Normally (at least as I look at it) globals are always reset at the
start (e.g. global_symbols), not reset at the end (as for
using_directives).  [I know really_free_pendings sets global_symbols =
NULL but to my mind that's just more for robustness sake, not for
preparing the machinery for the next time - I'm thinking of
buildsym_init as constructor-like and really_free_pendings as
destructor-like.]

So the code path here is anything that leaves using_directives != NULL
at the end of symbol expansion, and then coming back into the buildsym
machinery and calling cp_add_using_directives without having first
gone through finish_block_internal or push_context.

If you want to add more robustness, e.g. reset using_directives to
NULL in, say, really_free_pendings, to say trigger a segv if it's
errantly used outside of buildsym that'd be great.  But I think
buildsym_init is the right place to initialize it for the current
pass.



More information about the Gdb-patches mailing list