From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7649 invoked by alias); 21 Mar 2011 20:46:05 -0000 Received: (qmail 7424 invoked by uid 22791); 21 Mar 2011 20:46:04 -0000 X-SWARE-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 21 Mar 2011 20:45:32 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p2LKjVWG003823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 21 Mar 2011 16:45:31 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p2LKjUW2011869; Mon, 21 Mar 2011 16:45:31 -0400 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p2LKjTmN026122; Mon, 21 Mar 2011 16:45:30 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 6A4FE378491; Mon, 21 Mar 2011 14:45:29 -0600 (MDT) From: Tom Tromey To: Jan Kratochvil Cc: gdb-patches@sourceware.org Subject: Re: [patch 5/7] STT_GNU_IFUNC symbols reader References: <20110319211628.GF30867@host1.jankratochvil.net> Date: Mon, 21 Mar 2011 21:15:00 -0000 In-Reply-To: <20110319211628.GF30867@host1.jankratochvil.net> (Jan Kratochvil's message of "Sat, 19 Mar 2011 22:16:28 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-03/txt/msg00978.txt.bz2 >>>>> "Jan" == Jan Kratochvil 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 -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