This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [7/10] keep track of dependencies
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 11 May 2012 16:41:09 +0200
- Subject: Re: [7/10] keep track of dependencies
- References: <87zk9zabho.fsf@fleche.redhat.com> <20120426202743.GA23244@host2.jankratochvil.net> <87obpwox1y.fsf@fleche.redhat.com>
On Thu, 10 May 2012 17:50:01 +0200, Tom Tromey wrote:
> Jan> Why is RESULT_CHILDREN used here at all? Would not it be
> Jan> sufficient to just call htab_traverse for ALL_CHILDREN?
>
> Maybe it isn't a great reason, but it lets us easily avoid adding CUs
> without symbol tables. See recursively_compute_inclusions:
>
> if (get_symtab (per_cu) != NULL)
> VEC_safe_push (dwarf2_per_cu_ptr, *result, per_cu);
>
> So, RESULT_CHILDREN and ALL_CHILDREN do not have identical contents.
The 'get_symtab (per_cu) != NULL' conditional evaluation is "zero-cost", it
can be moved to the RESULT_CHILDREN processing (therefore to unify it as
ALL_CHILDREN processing), just one has to do one pre-scan instead of just
VEC_length.
Thanks,
Jan