This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch 5/7] STT_GNU_IFUNC symbols reader
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