Re: [patch 5/7] STT_GNU_IFUNC symbols reader

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Mon, 21 Mar 2011 21:45:29 +0100, Tom Tromey wrote:
> >>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
> Jan> +      htab = htab_create_alloc_ex (1, elf_gnu_ifunc_cache_hash,
> Jan> +				   elf_gnu_ifunc_cache_eq,
> Jan> +				   NULL, &objfile->objfile_obstack,
> Jan> +				   hashtab_obstack_allocate,
> Jan> +				   dummy_obstack_deallocate);
> 
> It seems just as easy to allocate the hash table so that rehashing
> doesn't waste memory.

To clarify the comment:

This statement is in elf_gnu_ifunc_record_cache, HTAB is used only for the
cache of STT_GNU_IFUNC resolved addresses where GDB explicitly had to figure
out the address due to a user request for breakpoint on that function.

That is usually only few of the functions will ever get stored by
elf_gnu_ifunc_record_cache into that hash even if the objfile has many
STT_GNU_IFUNC symbols.

Did you mean that GDB should make the hash size its maximum possible one, by
counting the STT_GNU_IFUNC symbols in that objfile?  I understand even an
occasional rehashing is more expensive than a larger than needed initial
allocation each time.

BTW the rehashing using non-deallocating hashtab_obstack_allocate already
commonly happens in current FSF GDB code.

While I do not want to oppose your constructive comment still I have to note
the value 1 may be IMO the optimal one during most of the GDB use cases. :-)


Thanks,
Jan