Re: [patch 5/7] STT_GNU_IFUNC symbols reader

[Tom Tromey <tromey@redhat.com>]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> it is questionable if it should not reside in gdb/elf-ifunc.c (like
Jan> bfd/elf-ifunc.c).  With the other patches it is over 400 LoC which
Jan> would make sense.  Unfortunately it needs some internal functions
Jan> of elfread.c which would need to be exposed, probably via new
Jan> elfread.h etc., I have no problem with the split but I tried it
Jan> (one also needs to modify configure.ac for the ELF exception) and
Jan> the split was not too clean.

What you did seems fine to me.

Jan> The elf_objfile_gnu_ifunc_cache_data hash table was implemented as
Jan> minimal symbols before.  But as these entries are found only during
Jan> the inferior runtime install_minimal_symbols has already finished
Jan> and there is no clean way how to add new minimal symbols, moreover
Jan> to make them visible for <tab>-completion etc.  Therefore it is
Jan> only an internal GDB cache now.

Also ok by me.

Jan> I was considering whether to delay the SYMBOL_GOT_PLT_SUFFIX
Jan> minimal symbols (those from .got.plt) reading only for the case
Jan> first STT_GNU_IFUNC is needed.  As the .got.plt section is
Jan> typically not big and there is rather needed an unrelated
Jan> optimization to make the symbols (incl. minimal symbols) reading
Jan> lazy and not to touch 150+ symbol files for LibreOffice when only
Jan> <5 of such files GDB needs to know I do not consider such
Jan> optimization relevant now.  With the lazy symbol files reading even
Jan> the .got.plt reading will get optimized along.  And for the few
Jan> really needed files it should not harm.

I agree.

Jan> Another issue is if it should not be rather located in OSABI.  But
Jan> this is an ELF feature, which matches neither OS nor ARCH.  Also
Jan> OSABI has no inheritance which makes implementation of such global
Jan> features a bit tedious.  I am interested in the opinion on the
Jan> OSABI way.

It seems harmless to do it this way.

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.

Tom