From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14538 invoked by alias); 21 Oct 2011 17:30:19 -0000 Received: (qmail 14516 invoked by uid 22791); 21 Oct 2011 17:30:17 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 21 Oct 2011 17:30:03 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 3BFB32BC0FC; Fri, 21 Oct 2011 13:30:03 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id h0N84tcsnJaH; Fri, 21 Oct 2011 13:30:03 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id DE0352BC0FF; Fri, 21 Oct 2011 13:30:01 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id EC41B145615; Fri, 21 Oct 2011 13:29:58 -0400 (EDT) Date: Fri, 21 Oct 2011 17:40:00 -0000 From: Joel Brobecker To: Jan Kratochvil Cc: gdb-patches@sourceware.org Subject: Re: [RFA/RFC] try ignoring bad PLT entries in ELF symbol tables Message-ID: <20111021172958.GH19246@adacore.com> References: <1318983817-29454-1-git-send-email-brobecker@adacore.com> <20111020194921.GA16613@host1.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111020194921.GA16613@host1.jankratochvil.net> User-Agent: Mutt/1.5.20 (2009-06-14) 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-10/txt/msg00599.txt.bz2 > > Normally, such entries either have a null value, or their value > > corresponds to an address in the PLT section. > > Do you have some such file with undefinde symbol and non-zero value? Do you mean, other than on ia64-hpux? My comment is just repeating what the comment in that file says, so I assume it's true somewhere. > > + if (strncmp (sect->name, ".plt", 4) != 0 > > + && bfd_get_section_by_name (abfd, ".plt") != NULL) > > At least the bfd_get_section_by_name result should be cached. I didn't think it was going to make much of a difference, since this only happens for symbols that point outside of the .plt section, which I am hoping would be seldom. But if others agree with the caching (or even if it does not really matter to them), it's no problem. As a datapoint, my executable has 96 undefined symbols for a total of roughly 1150 symbols in total. Total number of sections is almost 50 with .plt at index 30. That indeed suggest that we can get a good improvement in terms of performance, although I don't think it be noticeable as far as the user is concerned. I'll wait for an official review before making any adjustment. Thanks for your comments, -- Joel