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
- From: Tom Tromey <tromey at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 21 Mar 2011 14:45:29 -0600
- Subject: Re: [patch 5/7] STT_GNU_IFUNC symbols reader
- References: <20110319211628.GF30867@host1.jankratochvil.net>
>>>>> "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